03-14-2018 03:31 AM
I'm testing PUTN (per-user tunneled node) feature and it is very unstable. Sometimes it works, but most of the times it failed. I configured the switch to use DUR to download roles from ClearPass, which contains the secondary role to tunnel user traffic to the controller.
On ClearPass, I can see the client was successfully authenticated, but somehow the switch failed to setup the tunnel.
On the switch, I always see the following log (vlan disabled) when it failed:
Please give me some advice on this.
Re: PUTN unstable
Re: PUTN unstable
03-15-2018 02:45 AM - edited 03-15-2018 02:55 AM
After lots of testing it looks to me there's something wrong with the user-table on the controller. Let me describe in more detail. I want to onboard wired devices and here are the step-by-step:
1) Users plugs in their cable, then gets authenticated by 802.1X (PEAP-GTC specifically, since I do not join ClearPass to AD).
2) Upon successful authentication, ClearPass returns DUR to the switch, which tunnels user traffic to the controller on the secondary role "onboard-provisioning", which contains a captive portal to redirect users to onboard portal.
3) User downloads and runs Aruba QuickConnect, then gets authenticated by EAP-TLS. Upon successful authentication, ClearPass returns DUR to the switch, which tunnels user traffic to the controller on the secondary role "allow-any", which basically allows everything (for testing purposes).
The step that I'm always stuck at is step 3. I can see from ClearPass that I was successfully authenticated, and the switch also has no problem with downloading roles from ClearPass. But it does have problem when trying to apply this role. The log message was always "virtual LAN disabled" (2010 was the vlan that I tried to apply to user after being authenticated with EAP-TLS):
Checking on the controller, I saw the following (2009 was the vlan that I applied to user after being first authenticated by PEAP-GTC and redirected to onboard portal):
So, the controller still had the old sessions of user with old vlan. My guess is that when the switch tried to tunnel user traffic to the controller on vlan 2010, the controller rejected because it still had vlan 2009 applied to this user. That's why the switch showed vlan 2010 was disabled in its log messages and failed to apply this vlan to user. I did two other tests and the result seems to favor my guess:
+ I can onboard and authenticate successfully with EAP-TLS when I use the same vlan for onboard and post-onboard.
+ I can authenticate with EAP-TLS successfully as soon as the old sessions on the controller disappears (I don't know how to clear them, so my only option was to reboot the controller).
Of course that is just my guess. Maybe I've missed something. I really appreciate if anyone can share their experience on this.