Wireless Access

Having an odd issue with Dell Wyse thin clients. They are currently running on 7220 controller (Local) on 6.3.1.16 code and working fine. They are on a WPA2-AES network using 802.1X, the VAP has VLAN 216 assigned, and from the ClearPass RADIUS response, we are assigning VLAN 208. This is all working fine.

We upgraded a second controller (Master) to version 6.4.4.16 and failed APs over to upgrade the Local, but now those same devices fail during the VLAN change:

Nov 20 12:03:47  assg-vlan-req          *  00:0e:8e:50:2f:aa  44:48:c1:d2:87:24                 216  208  new vlan: dot1x for wireless
Nov 20 12:04:17  station-down           *  00:0e:8e:50:2f:aa  44:48:c1:d2:87:24                 -     -    

Everything is normal until we see "assg-vlan-req", then the station-down. If we change the configuration to start with 208 in our VAP, the authentication is successful with no issues.

I've also tried putting VLAN in user-role instead of VAP, but then we don't even complete the initial authentication.

I checked ClearPass Network Device and RFC3576 is enabled and device type is set to Aruba.

We've done this same upgrade to other controller Master/Local clusters with those same D10D devices, and have had no reported issues.

I'm running short on ideas on what to check / what to verify to see what's wrong. Any ideas or suggestions? These thin clients are not great wireless clients to begin with, so I think it's partly on them, but they work on the 6.3 code, they should work on 6.4.

Also, doesn't matter what VLAN we start with or end with, if it's the same for both, it's fine (no VLAN change). If it's different, then it fails at the same place.

rfc 3576 has nothing to do with it, unless you are doing something special after authentication.  How are you using 3576 in this context?

Use this command to see what is happening:

show ap client trail-info <client mac address>

Also type "show user-table ip <ip address of user>" to see why the user was assigned that VLAN:

Vlan default: 1, Assigned: 1, Current: 1 vlan-how: 1 DP assigned vlan:0

VLAN-how says how the user was assigned that VLAN.

VLAN Derivation Code Description
1 VLAN derived from user rule
2 VLAN derived from user role
3 VLAN derived from server rule
4 VLAN derived from Aruba vendor-specific attribute (VSA)
5 VLAN derived from Microsoft Tunnel attributes (Tunnel-Type, Tunnel Medium Type, and Tunnel Private Group ID)
6 VLAN assigned from derived role 

The reason I mentioned RFC3576 was because I saw an entry for initial VLAN, which is the one assigned in the VAP (216) and then I see an attempt to move to new VLAN (208), which is where it stop on this controller (6.4.4.16). I see the same steps in the other controller (running 6.3.1.16) and it goes through completely with no issues. Same configuration as it's Master (6.4) and Local (6.3).

The Wyse D10D never obtains an IP address and never fully associates, although we see successful authentications in ClearPass and pushing VLAN 208 in the enforcement, it never does the WPA handshake after telling it to go to VLAN 208.

Client Trail Info
-----------------
MAC                BSSID              ESSID      AP-name            VLAN  Deauth Reason                      Alert
---                -----              -----      -------            ----  -------------                      -----
00:0e:8e:50:2f:aa  44:48:c1:d2:87:34  DOT1X  44:48:c1:c5:28:72  216  STA has left and is disassociated  STA has left and is disassociated

Deauth Reason
-------------
Reason                             Timestamp
------                             ---------
STA has left and is disassociated  Nov 27 09:44:11

Alerts
------
Reason                             Timestamp
------                             ---------
STA has left and is disassociated  Nov 27 09:44:11
VLAN: New assignment               Nov 27 09:43:41

On the client, the logs show the following:

EAP: authenticating

EAP: authenticate phase - init

EAP: authenticate phase - identity

EAP: SSL connection handshaking . . .

EAP: SSL connection established!

EAP: authenticate (peap) phase 2 - init (v1)

EAP: authenticate (peap) phase 2 - identity

EAP: authenticate (peap) phase 2 (peap/mschapv2)

EAP: authenticate phase - success

EAP: encryption phase - init (wpa2-ccmp)

EAP: authenticate timeout.

EAP: authenticate fail

I enabled debugging for Security and this is the logs I received when attempting to have the device authenticate:

Nov 27 10:33:28 :124091:  <DBUG> |authmgr|  station_check_license_limits: mac 00:0e:8e:50:2f:aa  encr-algo:64.
Nov 27 10:33:28 :124093:  <DBUG> |authmgr|  Called mac_station_new() for mac 00:0e:8e:50:2f:aa.
Nov 27 10:33:28 :124103:  <DBUG> |authmgr|  Setting user 00:0e:8e:50:2f:aa aaa profile to dot1x-D10D, reason: ncfg_set_aaa_profile_defaults.
Nov 27 10:33:28 :124209:  <DBUG> |authmgr|  handle_sta_up_dn:2774 Updating vlan usage for MAC=00:0e:8e:50:2f:aa with vlan 216 apname 44:48:c1:c5:28:72
Nov 27 10:33:28 :124004:  <DBUG> |authmgr|  AUTH GSM: PMK cache DELETE for station (00:0e:8e:50:2f:aa, 44:48:c1:d2:87:34)
Nov 27 10:33:28 :124105:  <DBUG> |authmgr|  MM: mac=00:0e:8e:50:2f:aa, state=4, name=, role=logon, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=1.
Nov 27 10:33:28 :121038:  <DBUG> |authmgr|  Save Class in station for MAC 00:0e:8e:50:2f:aa.
Nov 27 10:33:28 :124003:  <INFO> |authmgr|  Authentication result=Authentication Successful(0), method=802.1x, server=c-31-clearpass, user=00:0e:8e:50:2f:aa
Nov 27 10:33:28 :124105:  <DBUG> |authmgr|  MM: mac=00:0e:8e:50:2f:aa, state=3, name=w123, role=dot1x-user, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=1.
Nov 27 10:33:28 :124105:  <DBUG> |authmgr|  MM: mac=00:0e:8e:50:2f:aa, state=3, name=w123, role=dot1x-user, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=0.
Nov 27 10:33:58 :124105:  <DBUG> |authmgr|  MM: mac=00:0e:8e:50:2f:aa, state=5, name=w123, role=dot1x-user, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=1.
Nov 27 10:33:58 :124090:  <DBUG> |authmgr|  Free macuser 0x0x2b33844 and user 0x0x2d875034 for mac 00:0e:8e:50:2f:aa.
Nov 27 10:33:58 :124091:  <DBUG> |authmgr|  station_check_license_limits: mac 00:0e:8e:50:2f:aa  encr-algo:64.
Nov 27 10:33:58 :124093:  <DBUG> |authmgr|  Called mac_station_new() for mac 00:0e:8e:50:2f:aa.
Nov 27 10:33:58 :124103:  <DBUG> |authmgr|  Setting user 00:0e:8e:50:2f:aa aaa profile to dot1x-D10D, reason: ncfg_set_aaa_profile_defaults.
Nov 27 10:33:58 :124209:  <DBUG> |authmgr|  handle_sta_up_dn:2774 Updating vlan usage for MAC=00:0e:8e:50:2f:aa with vlan 216 apname 44:48:c1:c5:28:72
Nov 27 10:33:58 :124004:  <DBUG> |authmgr|  AUTH GSM: PMK cache DELETE for station (00:0e:8e:50:2f:aa, 44:48:c1:d2:87:24)
Nov 27 10:33:58 :124105:  <DBUG> |authmgr|  MM: mac=00:0e:8e:50:2f:aa, state=4, name=, role=logon, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=1.
Nov 27 10:33:59 :121038:  <DBUG> |authmgr|  Save Class in station for MAC 00:0e:8e:50:2f:aa.
Nov 27 10:33:59 :124003:  <INFO> |authmgr|  Authentication result=Authentication Successful(0), method=802.1x, server=c-31-clearpass, user=00:0e:8e:50:2f:aa
Nov 27 10:33:59 :124105:  <DBUG> |authmgr|  MM: mac=00:0e:8e:50:2f:aa, state=3, name=w123, role=dot1x-user, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=1.
Nov 27 10:33:59 :124105:  <DBUG> |authmgr|  MM: mac=00:0e:8e:50:2f:aa, state=3, name=w123, role=dot1x-user, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=0.
Nov 27 10:34:29 :124105:  <DBUG> |authmgr|  MM: mac=00:0e:8e:50:2f:aa, state=5, name=w123, role=dot1x-user, dev_type=, ipv4=0.0.0.0, ipv6=0.0.0.0, new_rec=1.
Nov 27 10:34:29 :124090:  <DBUG> |authmgr|  Free macuser 0x0x2922cdc and user 0x0x2ca189dc for mac 00:0e:8e:50:2f:aa.

I disabled Validate PMKID in the 802.1X profile and it connected / authenticated successfully. These Dell Wyse D10D clients are notorious for having roaming issues and I wonder if because the client initially authenticated to Controller A and then the APs go down for reprovisioning and it roams to an AP on Controller B, attempts to utilize OKC / PMK for faster roaming and something breaks. By forcing to go through a full re-authentication, it seems to have worked.