Hello,
We are a group of 4 Aruba IAP205 that are configured with one of them as a master.
We have configured an SSID that does 802.1X against our freeradius instance. The freeradius does NTLM authentication to send Access-Accept or Access-Request depending on whether a user belongs to a specific Active Directory group or not. After this, the freeradius does a lookup on LDAP groups to send the Aruba-User-Vlan attributes. We only do user authentication and not machine authentication.
We've confirmed with freeradius debug and with Wireshark traffic captures (screenshot attached) that the attributes are systematically sent correctly.
The issue is that sometimes Aruba accepts the VLAN attribute and puts the user in the right VLAN and some other times Aruba ignores the VLAN attribute and puts the user in the default VLAN. This happens for the same user which means that 2 of his devices are in the default VLAN but one is in the correct VLAN.
The following logs shows the debug log from one of the connection attempts that ends up in the wrong VLAN :
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] User-Name: dude1
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] Vendor-Specific: \261\013\250`M\251bq\340\033`X\377j\024g\326,\207\264\242\200U(\245\362\377f\363\347\001\224L\213\327\206\252T\343\226\224\237\212|\032\364\315\226T\300
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] Vendor-Specific: \276_\003\266\266\300)\020
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] EAP-Message: \003\007
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] PW_RADIUS_ID: \211
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] Rad-Length: 172
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] PW_RADIUS_CODE: \002
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] PW_RAD_AUTHENTICATOR: \\275\3245X\357['\363\003I\310`\207.6
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] Server-Name: t_hq-networkserv
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] dot1x-authentication-type: EAP-TTLS
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_aal.c:2010] mac-address: cc20e8b94543
<172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]: VLAN_HIGHER_PRECEDENCE_THAN_STORED: 1064: vlan_rule_index=ff, sap_sta->vlanhow=ff, precedence_result=1
<172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]: __HIGHER_PRECEDENCE_COMPARE: 1041: matched_rule_index=37fff, sap_sta->acl_rule_index=0, precedence_result=1
stm[1852]: <501146> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> Derive user role: cc:20:e8:b9:45:43 Match user role acl 136 rule_index 0x37fff
stm[1852]: <304008> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |ap| >>> update_mac_acl mac:cc:20:e8:b9:45:43 acl:136 fw_mode:1 vlan:172
stm[1852]: <501197> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> Send user role info: mac-cc:20:e8:b9:45:43, acl-136, idx-229375, essid-SuperCorp Zuper Secure
<172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]: stm_send_sta_update: Sending sta update msg to CLI0, mac='cc:20:e8:b9:45:43'
stm[1852]: <501149> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> Send radius auth info: authtime Mon Feb 29 13:59:51 2016 timeouts 0, authdone 1
<172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]: stm_start_acct_for_post_1xauth_user: 15815: ip not ready for sta 'cc:20:e8:b9:45:43'
stm[1852]: <524038> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> wpa2_tx_eapolkey_mesg1: FT sending key1
cli[1810]: <541004> <WARN> <172.17.16.2 84:D4:7E:C0:A0:FA> recv_stm_sta_update: receive station msg, mac-cc:20:e8:b9:45:43 bssid-84:d4:7e:8a:0f:b1 ssid-SuperCorp Zuper Secure.
cli[1810]: <541059> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> recv_stm_sta_update: Set calea state, Station cc:20:e8:b9:45:43, intercept 0.
cli[1810]: <541030> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> recv_stm_sta_update: Set user role, Station cc:20:e8:b9:45:43 essid SuperCorp Zuper Secure role 136 rule_index 0x37fff.
cli[1810]: <541004> <WARN> <172.17.16.2 84:D4:7E:C0:A0:FA> recv_stm_sta_update: receive station msg, mac-cc:20:e8:b9:45:43 bssid-84:d4:7e:8a:0f:b1 ssid-SuperCorp Zuper Secure.
cli[1810]: <541044> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> recv_stm_sta_update: set reauth ctx for client-cc:20:e8:b9:45:43, timeout-60, authtime-1456750791, auth age-0, essid-SuperCorp Zuper Secure.
cli[1810]: <541034> <INFO> <172.17.16.2 84:D4:7E:C0:A0:FA> recv_stm_sta_update: set user idle timeout, user-cc:20:e8:b9:45:43 timeout-1000.
cli[1810]: <541006> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> recv_stm_sta_update: Set auth state, Station cc:20:e8:b9:45:43, authenticated 1.
stm[1852]: <524079> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> FT (derive_ptk_ft): essid:SuperCorp Zuper Secure, bssid:84:d4:7e:8a:0f:b1 ukey:00xa, mkey:0xa, psk:no,tkip:no
The following logs shows the debug log from one of the connection attempts that ends up in the correct VLAN :
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1695] Sending radius request to t_hq-networkserv:127.0.0.1:2630 id:143,len:216
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] User-Name: dude1
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] NAS-IP-Address: 127.0.0.1
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] NAS-Port-Id: 0
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] NAS-Identifier: nonasid
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] NAS-Port-Type: 19
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] Calling-Station-Id: 98e0d9ae8329
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] Called-Station-Id: 84d47ec0a0fa
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] Service-Type: Login-User
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] Framed-MTU: 1100
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] EAP-Message: \002\006
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] State: \232
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] Aruba-Essid-Name: SuperCorp Zuper Secure
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] Aruba-Location-Id: ARU-205-LAU-01
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] Aruba-AP-Group: ARU-205-LAU-01
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_server.c:1705] Message-Auth: a\024D\034-\36646\3444\257\224\034y\027\306
<172.17.16.2 84:D4:7E:C0:A0:FA> radiusd-term[2413]: radius_pairmove: 959: why request for zero mem?
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_request.c:76] Find Request: id=143, srv=127.0.0.1, fd=17
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_request.c:82] Current entry: srv=127.0.0.1, fd=17
stm[1852]: <121031> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |aaa| [rc_request.c:37] Del Request: id=143, srv=127.0.0.1, fd=17
stm[1852]: <121050> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> in rc_aal.c(server_cbh),auth result = 0, with user name = dude1
stm[1852]: <121050> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> ACESS_ACCEPT or ACCESS_REJECT message received
stm[1852]: <501201> <NOTI> <172.17.16.2 84:D4:7E:C0:A0:FA> update_acl_for_post_1xauth_user598: mac-98:e0:d9:ae:83:29, role-SuperCorp Zuper Secure, intercept-0
stm[1852]: <501142> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> Derive user vlan: 98:e0:d9:ae:83:29 Derive user Vlan 1700 from VSA
<172.17.16.2 84:D4:7E:C0:A0:FA> stm[1852]: __HIGHER_PRECEDENCE_COMPARE: 1041: matched_rule_index=37fff, sap_sta->acl_rule_index=0, precedence_result=1
stm[1852]: <501146> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> Derive user role: 98:e0:d9:ae:83:29 Match user role acl 136 rule_index 0x37fff
stm[1852]: <304008> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> |ap| >>> update_mac_acl mac:98:e0:d9:ae:83:29 acl:136 fw_mode:1 vlan:1700
stm[1852]: <501197> <DBUG> <172.17.16.2 84:D4:7E:C0:A0:FA> Send user role info: mac-98:e0:d9:ae:83:29, acl-136, idx-229375, essid-SuperCorp Zuper Secure
I have highlighted what I think are the relevant lines in the debug logs. It seems that when it fails, the VLAN allocation is overriden by some role or ACL of some sort. The issue is that there are not other roles or ACL except the ones that are included by default.
We've also tried using the Aruba-User-Role attribute to see if it would work better but the exact same symptoms occur as well. We've also tried with the Microsoft-style Tunnel attributes but the end-result is the same in this case as well.
So, what are we doing incorrectly ? How can we troubleshoot this further ?
Thank you in advance for your help.
Antoine