So we made some progress, found a few issues, indeed some of it related to the CoA server not having the correct password. We also find discrepancies between the role-mapping and policy so we recreated and simplified both. Although CoA works now, and roles are pushed and appear correct we still experience unexpected behavior.
We are now able to use CoA, unfortunately both DUR roles and roles locally defined on the controller giving us strange behavior, this is what happens:
- When we log in to the PC when it is not connected to our WLAN everything works out it seems, we can ping the gateway and connect to the internet
- When we only use machine authentication, meaning before logging into the PC we connect to the WLAN, we are receiving the correct role from Clearpass and it is visible in the controller
- When logging in the user authentication is triggered and we are receiving the correct role from ClearPass, it is visible in the controller, but the behavior is strange. We were able to ping some other users in the subnet but not the gateway which is a switch upstream from the controller.
A packet capture shows the Client trying to ARP for the Gateway, but it never receives this information back.
The switch connected to our ESXi host has an ARP entry for the client (this might be an old entry though)
Probably not enough to go by but thought I share it.
------------------------------
Martijn van Overbeek
Architect, Netcraftsmen a BlueAlly Company
------------------------------
Original Message:
Sent: May 08, 2025 08:28 AM
From: mvanoverbeek
Subject: TEAP and CoA and DUR
Thanks/Dankjewel Herman, great questions!
And you are correct, my apologies for my mistakes, the customer is actually transitioning to EAP-TLS for the client-auth as well, machine was already EAP-TLS. Loads of questions to follow up on. One thing I do remember and need to double check is the "RADIUS key". Of course we have configured the RADIUS key for RADIUS itself but I am reading this article https://arubanetworking.hpe.com/techdocs/ClearPass/6.11/PolicyManager/Content/Deploy/Aruba%20Controller%20Configuration/RFC_server_configure.htm
that states I have to configure a password under "Server Options". I will verify this setting and also the other insightful questions you posed.
------------------------------
Martijn van Overbeek
Architect, Netcraftsmen a BlueAlly Company
------------------------------
Original Message:
Sent: May 08, 2025 04:34 AM
From: Herman Robers
Subject: TEAP and CoA and DUR
TEAP doesn't have an outer-method, think only PEAP has inner and outer methods (configurable). MSCHAPv2 is strongly deprecated because it's security has been broken for many years and should not be used anymore; move to EAP-TLS instead.
But question was around the CoA. On the 'did you check', do you have accounting enabled? Can you do a manual 'Change Status' from Access Tracker? How does the CoA fail, do you see an error message (not authorized, attributes missing, timeout, other)? Do you see something on your controller in the logs or in 'show aaa rfc-3576-server statistics'? Does the CoA even reach the controllers? Does CoA work on this ClearPass and Controller for other purposes? Note that with a ClearPass virtual IP, the CoA originates from the ClearPass virtual IP, so that needs to be listed as RFC3576/CoA server in your controllers.
Enough questions?
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
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.