So the VLAN that tunneled devices get does use DHCP. It's the same VLAN that our wireless guest users go into. The VLAN already has the IP of the clearpass cluster listed in the group of IP-Helpers on our core switches. However, I did not set up the controller and am unfamiliar with any DHCP settings that may exist there?
It's very possible, if there's some hidden DHCP options that I'm not aware of on the controller, that this may clear up several other issues i've been encountering, including devices that are PXE booting and having issues sending their attribute information as well.
Original Message:
Sent: Apr 30, 2025 03:04 AM
From: Herman Robers
Subject: Issue with MAC-Auth and tunneling without preauth-role
In order to get profiling information in, you would need to get (unknown) clients in a role that allows at least DHCP, and in a VLAN that has an ip-helper (or DHCP relay) to the ClearPass server. Goal is that the DHCP request reach the ClearPass server for profiling purposes (ClearPass will NOT respond with an IP, so make sure you have a real DHCP server as well).
If you tunnel the traffic for unknown devices, if that is LUR-UBT-User, the traffic is tunneled to the controller/gateway, there you can easily make sure DHCP is allowed and forwarded to the ClearPass.
In the case you are not fully familiar with how this works, it may be good to ask your partner to have a look together. For someone who fully understands the working, it will be trivial to make this work.
------------------------------
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.
Original Message:
Sent: Apr 29, 2025 11:34 AM
From: HornAlum
Subject: Issue with MAC-Auth and tunneling without preauth-role
Good morning! I am still in the very early stages of a Clearpass and Wired security deployment/testing. I'm running into a strange issue on the switches running CX and some of my Aruba AP's.
Our Aruba AP's use a MAC-AUTH service to authenticate to Clearpass. Right now, my Role Mappping Policy looks for the O/S Family to equal "Aruba" and the category to equal "Access Points" in order for clearpass to assign it the "AP" role. Our enforcement policy would then give it a Local User Role that basically allows the device full access. The default role of our MAC-AUTH service would be to tunnel devices to our Aruba wireless controller where firewall policies can be applied in order to deal with devices we do not recognize
When one of the Aruba AP's boots up and hits Clearpass, it doesn't pass all of the device fingerprint information to ClearPass, so ClearPass designates the default policy we have of tunneling the device to our Aruba controller, by assigning the device the local user tunnel role. No matter how many times I boot the device, it never passes all of the information to Clearpass.
With my testing, I've gone as far to completely remove any "Deny" statements in the ACL that is applied to the role on the wireless controller/mobility master. The VLAN that it drops those devices into should have full access to clearpass, etc.
Here is the port-access client list. Devices are given that "LUR-UBT-User" role and tunneled off. The AP is on interface 1/1/3
6300(config-if)# show port-access clients
Port Access Clients
RADIUS overridden user roles are suffixed with '*'
Flags: Onboarding-Method|Mode|Device-Type|Status
Onboarding-Method: 1x 802.1X, ma MAC-Auth, ps Port-Security, dp Device-Profile
Mode: c Client-Mode, d Device-Mode, m Multi-Domain
Device-Type: d Data, v Voice
Status: s Success, f Failed, p In-Progress, d Role-Download-Failed
--------------------------------------------------------------------------------------------------------------
Port Client-Name IPv4-Address User-Role VLAN Flags
--------------------------------------------------------------------------------------------------------------
1/1/1 host/SR2160-TEST.cdn... 10.11.88.20 COD-MACHINE multi 1x|c|-|s
1/1/3 b45d50c82a60 10.11.88.243 LUR-UBT-User (u)4091 ma|c|-|s
Now .. what I've found is: If I issue this the "preauth-role" command to the interface and assign it one of the local roles on the switch, the device is able to pass all of the necessary device attributes to Clearpass, and the device is profiled properly and given the correct role.
6300(config-if)# show run interface 1/1/3
interface 1/1/3
no shutdown
mtu 9198
no routing
vlan trunk native 1188
vlan trunk allowed 1188,1190
spanning-tree port-type admin-edge
aaa authentication port-access client-limit 12
aaa authentication port-access preauth-role COD-MACHINE
aaa authentication port-access dot1x authenticator
eapol-timeout 10
max-eapol-requests 1
max-retries 1
enable
aaa authentication port-access mac-auth
enable
exit
Here, 1188 is my data vlan, and 1190 is my voice vlan, for phones. If i use the pre-auth role of COD-MACHINE, the device is placed in the normal 1188 vlan for initial authorization, and it communicates perfectly well with clearpass. Below, you can see the authorization attributes are now passed into Clearpass
The device is given the "COD-AP" role and enforcement policy gives it the "COD-MACHINE" user role to pass to the switch
--------------------------------------------------------------------------------------------------------------
Port Client-Name IPv4-Address User-Role VLAN Flags
--------------------------------------------------------------------------------------------------------------
1/1/1 host/SR2160-TEST.cdn... 10.11.88.20 COD-MACHINE multi 1x|c|-|s
1/1/3 b45d50c82a60 10.11.88.243 COD-MACHINE multi ma|c|-|s
Is this expected behavior? perhaps I'm missing something with the allowed vlans and the tunnel node vlan?
Would love some input