Security

Reply
New Contributor
Posts: 2
Registered: ‎02-29-2016

Aruba ignoring freeradius VLAN attributes

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

Guru Elite
Posts: 20,993
Registered: ‎03-29-2007

Re: Aruba ignoring freeradius VLAN attributes

What version of Aruba Instant is this?



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

New Contributor
Posts: 2
Registered: ‎02-29-2016

Re: Aruba ignoring freeradius VLAN attributes

The version of Instant is 6.4.2.6-4.1.1.11_52666.

Guru Elite
Posts: 20,993
Registered: ‎03-29-2007

Re: Aruba ignoring freeradius VLAN attributes

Itteam, we have to open a tac case to review your setup.  Please pm me your email address so that we can do that.



Colin Joseph
Aruba Customer Engineering

Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base

Search Airheads
Showing results for 
Search instead for 
Did you mean: