a week ago
I have an issue I'm trying to solve, and the topology is quirky.
An Aruba controller (6.5.1.x) is applying a AAA-wired policy to all clients coming in from tunneled-node ports on switches - ProCurve switches.
However, these clients are wireless clients that get locally bridged from HP-Unified APs, not Aruba APs. After they authenticate to the wireless on the HP-U APs, they drop onto the wire, enter the tunnel, GRE to the controller and get the AAA policy to grab an initial role. Client gets an IP, communicates... splendid. Works great for an Open SSID. I can use ClearPass to perform a MAC-Auth on the mac address of the incoming client, and that piece works.
What doesn't appear to be working is using an 802.1X EAP-PEAP WLAN from the same HP-U AP, dropped onto the same VLAN. Strange symptoms. Client can authenticate (HPU checks ClearPass, and client successfully authenticates), but cannot grab a DHCP address or communicate further - so I statically assign a valid IP for it so the association doesn't keep dropping (no traffic can pass). But here's the weird part: the controller performs the MAC-Auth for the client ("show auth-tracebuf mac MA:CA:DD:RE:SS:ES" gives this) but doesn't create a user. However "show log user-debug mac MA:CA:DD:RE:SS:ES" shows the client being created, role assigned, vlan assigned (no change), and everything, and it notices "|authmgr| dot1x_supplicant_up(): MAC:xx:xx:xx:xx:xx:xx, pmkid_present=False, pmkid:N/A" in the debug logs.
I thought it had something to do with the 802.1X aaa-wired profile on there - since the client has already completed the 802.1X authentication when it attached to the HP-U wireless, I thought it wouldn't like being prompted again - but this didn't change anything. Removing both MAC and 802.1X from the aaa-wired profile doesn't change what happens, either.
I'm stumped. 2 main questions I have then:
1. What is happening in the controller to prevent clients from passing traffic or being born as a user despite hitting the aaa initial role and auth-tracebuf showing auth messages?
2. Can an 802.1X client supplicant complete two successive 802.1X rounds of authentications? Does it get confused? Or does the controller?
A little clarity here would be appreciated. Thanks for reading!
a week ago - last edited a week ago