Wireless Access

last person joined: 20 hours ago 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Back to discussions
Expand all | Collapse all

RAP Persistent and 802.1X

This thread has been viewed 4 times

  • 1.  RAP Persistent and 802.1X

    Posted Sep 10, 2018 11:49 AM
    Hi to All and thanks in advance for your support.
    I have RAPs environment configured in persistent mode and 802.1x SSID configured in bridge mode.
    Aruba OS is 6.4.4.16.
     
    The RADIUS communication is only working when there is controller connectivity.
    NPS are installed on the local and central sites. However already authenticated clients should be able to continue to work locally when there is a controller connectivity outage.
     
    When I break connectivity with the controller, I still have connectivity for authenticated clients but no connectivity for NEW 802.1x clients.
     
    The 802.1x SSID remains broadcasted however.
     
    Is this a limitation of the RAP in persistent mode or I wrong something?
     
    From the UG I read:

    "ESSID is up when the AP contacts the controllerand stays up if connectivity is disrupted with the controller.

    SSID configuration obtained from the controller.

    Designed for 802.1x SSIDs"

     

    Thanks and Best Regards!



  • 2.  RE: RAP Persistent and 802.1X

    EMPLOYEE
    Posted Sep 10, 2018 12:12 PM

    What is the behavior you are expecting to see?

     

    Controller based APs do rely on the controller to handle user authentications. That authentication traffic is independent of the forwarding mode (tunnel, bridge, split, decrypt).

     

    When you set the SSID to persistent, the RAP is instructed to continue advertising the SSID even though it can not contact the controller. The default behavior would be to drop the SSID until connectivity is resumed. Now, since the authentication traffic requires the controller, the behavior you're seeing is expected.



  • 3.  RE: RAP Persistent and 802.1X

    Posted Sep 10, 2018 05:02 PM

    Thanks Charlie for your quickly reply and explanation.

     

    When from UG I read "design for 802.1x" I was thinking (and hoping) that RAP in persistent configuration, in absence of controller, performed local authentication acting as radius client.

    A behavior similar to Cisco in flexconnect configuration.

     

    Please, do you confirm that the descripted scenario in my first post is the expected behavior?

    If YES, the 802.1x client authenticated before the absence of controller will be authenticated until a timeout or until a roaming attempt, right?

     

    Thanks and Best Regards!

     

     

     



  • 4.  RE: RAP Persistent and 802.1X
    Best Answer

    EMPLOYEE
    Posted Sep 10, 2018 08:49 PM
    alessandro.chiorra@nbservice.it wrote:

    Thanks Charlie for your quickly reply and explanation.

     

    When from UG I read "design for 802.1x" I was thinking (and hoping) that RAP in persistent configuration, in absence of controller, performed local authentication acting as radius client.

    A behavior similar to Cisco in flexconnect configuration.

     

    Please, do you confirm that the descripted scenario in my first post is the expected behavior?

    If YES, the 802.1x client authenticated before the absence of controller will be authenticated until a timeout or until a roaming attempt, right?

     

    Thanks and Best Regards!

     

     

     

    Correct, RAP will not attempt local authentication in the absense of controller connectivity. For that time of environment, I would recommend APs running in Instant mode, with Instant-VPN back to the central controller for full local processing with the ability to terminate user traffic back to the controller when needed.

     

    The behavior you're seeing (no new users authenticating when the controller is unreachable) is expected.

     

    That said, yes, as long as the client does not roam, and a reauthentication timer is not hit for the active client, bridge mode clients with a persistent SSID should continue to function.