Security

 View Only
last person joined: 3 days ago 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Back to discussions
Expand all | Collapse all

manual CoA port bounce

This thread has been viewed 64 times

  • 1.  manual CoA port bounce

    Posted Aug 24, 2022 09:34 PM
    I'm able to send CoA port bounce from the "Change Status" button in access tracker when viewing a succesfully authenticated client, but is there a way I can manually send one for a rejected client?


  • 2.  RE: manual CoA port bounce

    Posted Aug 25, 2022 04:04 AM
    No, you will not be able to send a CoA for a rejected client, because the CoA is tied to a session, and for a reject there is no session.

    For this specific reason, I try to always return an accept, but with a quarantine user-role or VLAN. Another reason to always return an Accept, is that if a client is rejected, it will try to re-authenticate (and may flood your access-tracker), where authenticated clients will just sit on the network.

    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------

    Original Message


  • 3.  RE: manual CoA port bounce

    Posted Sep 15, 2022 10:41 PM
    Hi Herman,

    What will you tell customer that always wants to prioritize reject/deny over quarantined for their unwanted devices , aside from maybe DHCP lease issue (if we keep all devices in the network the dhcp server will run out of lease IP).

    I just want a second opinion about this thing, as I agree with you that reject will flood the access tracker.
    Original Message


  • 4.  RE: manual CoA port bounce

    Posted Sep 16, 2022 01:45 AM
    How about a justification around profiling?  If you completely the block the client, all ClearPass will know is the MAC address (maybe Device Sensor information from a Cisco switch via RADIUS Accounting).  You have to actually let the client do something in order for ClearPass to get the profiling data.
    Original Message


  • 5.  RE: manual CoA port bounce

    Posted Sep 16, 2022 10:35 AM
    If you send an accept but put clients in a role/VLAN that goes nowhere you would even have the option to run profiling in that role/VLAN. If you name the role or VLAN: reject, your customer may even accept this. Returning a RADIUS Reject is something that you should avoid in most cases. I would position a REJECT in Access Tracker as a system/policy failure of the RADIUS system. ACCEPT is a sign that an access decision has been made, and it's fine to return a reject role to get the same result for the client, but stay in control.

    With quarantine, I more meant a role/VLAN where devices have very limited access. And you can have multiple of those, like one for clients you know and must be contained, and another for unknown clients that you don't want to provide access.

    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------

    Original Message


  • 6.  RE: manual CoA port bounce

    Posted Sep 14, 2023 12:33 PM

    Hello Herman,

    This is perhaps somewhat related but in a different direction:

    We are currently authenticating users against AD to access the device registration page. The CapPort page and the auth source is configured within the Guest>>Administration>>OperatorLogins part of ClearPass; this triggers a WebAuth service with the sole purpose of sending a service disconnect upon device registration being completed. I have added the AOS-CX Port Bounce enforcement profile to this service but it does not trigger the port bounce. The reason it is failing, from what TAC said, is that the service is a WebAuth service that is negotiated between the client and ClearPass with no network access device information being included in the transaction, and therefore nowhere to send the port bounce.

    Is there a way within this config to trigger the port bounce?

    Or, is there a better way to AD auth Students to allow them to access the device registration portal and add devices for MAC auth network access? 

    Thanks in advance!


    Original Message


  • 7.  RE: manual CoA port bounce

    Posted Sep 21, 2023 04:08 AM

    Not sure about your specific situation, but based on what you wrote the following may be useful to get better understanding:

    • In order to send a CoA, ClearPass needs to have authenticated the MAC address of the client (and think having received at least one accounting packet), otherwise it will not know where to send the CoA to. Also a switch only allows a CoA for an 'active authenticated' session. But if you have MAC authentication enabled and for unknown devices do a redirect to your ClearPass, the active session should be there in both the switch and ClearPass.
    • In order to send a CoA from a WebAuth, the client MAC address has to be known to ClearPass. Because WebAuth typically crosses multiple routers, the MAC address from the HTTPS request cannot be used for that. If you have a Web Redirect, the switch/AP/gateway/controller injects the client MAC address in the redirect URL (mac=xx:xx:xx:xx:xx:xx) and ClearPass can learn the MAC from there. So if your users hit the ClearPass WebAuth page without being redirected, ClearPass does not even know for with MAC address to send the CoA.

    Not sure which of the two parts you missed. If it is the second, what you could do is try a dummy redirect, like you configure the switch to only redirect a specific IP (for example 10.254.1.1 if that is not used in your infrastructure and put a DNS name like: reauth.my.domain to it), and redirect that to your ClearPass. Then instead of pointing your client for the WebAuth to your ClearPass, point it to http://reauth.my.domain; note the http! not https, and that will then include the client MAC into the URL.

    With understanding of the above, other approaches may work as well, as long as ClearPass knows the client's MAC address both on the Guest/Login portal and on the network (MAC auth).



    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------

    Original Message


  • 8.  RE: manual CoA port bounce

    Posted Sep 22, 2023 11:53 AM

    Hello Herman,

    Thank you for your time and always helpful and clarifying explanations!

    Between my question and your response I have come up with this working process that hinges on the device not being completely added to the Endpoint Repository. I will also work on the redirect approach you detailed which would potentially negate the need for some of this configuration.

    Below is the working configuration I came up with to provide port bounce to Operator Login Device Registration clients. Please look this over and let me know if you see any issues with this approach:

    port-access role Dorm-CaptivePortal

        associate captive-portal-profile GU_Dorm_Ethernet

        associate policy captive-portal-policy

        reauth-period 10

     

    aaa authentication port-access captive-portal-profile Dorm-CaptivePortal

        url https://npm/guest/auth_login.php

                  

     

    port-access role Dorm-CaptivePortal

        associate captive-portal-profile Dorm-CaptivePortal

        associate policy captive-portal-policy

        reauth-period 10

        vlan access name ZagReg

     

    port-access role Dorm-Intermediate

        associate policy any

        reauth-period 10

        vlan access name Student

                  

    port-access role Dorm-Access

        associate policy any

        reauth-period 3600

        vlan access name Student        

     

    interface 1/1/1

        no shutdown

        mtu 9198

        no routing

        vlan access 555

        loop-protect

        port-access fallback-role Dorm-CaptivePortal

        port-access onboarding-method concurrent enable

        aaa authentication port-access dot1x authenticator

            enable

        aaa authentication port-access mac-auth

            enable

        client track ip enable

        client track ip update-interval 300

     

    On the router, the Student VLAN has "ip helper-address" pointing to ClearPass in addition to the DHCP server.

    The ZagReg VLAN does not have the same IP helper.

     

    Scenario:

     

    Client plugs in and fails mac-auth and fallback happens allowing device to grab IP from 555 network which is routed on the firewall and only allowed to ClearPass and DNS.

     

    show port-access clients

    c 1/1/3    50:7b:9d:37:25:93                Success              Dorm-CaptivePortal, Fallback

    Foley-TEST(config)# show client ip

    50:7b:9d:37:25:93         1/1/3            555              10.55.0.13 

     

    Captive portal is presented, login is completed and device is registered.

     

    Enforcement profile condition 2: Dorm-Intermediate Role sent to switch assigning Student VLAN but port bounce does not trigger for some reason the first time so client retains CapPort IP addressing. Endpoint repository has MAC but not device category information from IP-helper. Reauth set to 10seconds for this role forcing the same service to trigger again finally resulting in port bounce.

     

    Foley-TEST(config)# show port-access clients

    c 1/1/3    50:7b:9d:37:25:93 mac-auth       Success              Dorm-Intermediate 

    Foley-TEST(config)# show client ip

    50:7b:9d:37:25:93         1/1/3            156              10.55.0.13

     

    Port-Bounce causes DHCP renew on Student VLAN resulting in the device category info being sent to ClearPass from IP-Helper. This triggers enforcement profile condition 1 and the Doorm Access role to be sent to the switch which is configured for 3600 second reauth without port-bounce.

     

    Foley-TEST(config)# show port-access clients

    c 1/1/3    50:7b:9d:37:25:93 mac-auth       Success              Dorm-Access

    Foley-TEST(config)# show client ip

    50:7b:9d:37:25:93         1/1/3            156              147.222.156.117 

     

    Thanks!




  • 9.  RE: manual CoA port bounce

    Posted Oct 02, 2023 07:21 AM

    Do you have a ClearPass cluster? And are authentication running to another node than the publisher? In that case it can take a few seconds between the endpoint is updated and the updated endpoint information is replicated back from the publisher to all your subscribers. In Captive Portal you have the 'Login Delay' that specifically for that captive portal introduces a wait time to allow endpoint data to be replicated. There also is a global RADIUS CoA delay under the Service Config - Service Parameters - Async network service, that defaults to 2 seconds delay.



    ------------------------------
    Herman Robers
    ------------------------
    If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

    In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
    ------------------------------

    Original Message


  • 10.  RE: manual CoA port bounce

    Posted Jan 18, 2024 06:45 PM

    Yes it is a cluster of 2 hardware devices, soon to become a 3 VM cluster.

    So far I have not been able to make anything aside from the above detailed config work properly. Which in my perspective is fine so far in testing, I just wanted to see if you noticed any potential gotchas. 

    Thanks again 


    Original Message