Wireless Access

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

You may try to return both Aruba-User-Role and Aruba-User-VLAN as separate RADIUS return attributes during the authentication instead of assigning the VLAN by role to see if that improves.

What you can do to get rid of the double IP addresses is 'aaa user delete all' on the controller CLI to get rid of all 'stale' user entries. If the wrong IP addresses then re-appear, there may be something different wrong. Further, with 'show ap association' you can see the actual VLAN assigned to this user, where it's more important that you see the correct VLAN there. If a client uses an old IP address (but in the assigned VLAN), that IP address will show up under the client, but the client will not be able to communicate (with that IP) as it's in the wrong VLAN. Sometimes you may see IP addresses from cellular networks show up in the controller for devices that when roaming from cellular to WLAN, it still sends some traffic with the cellular IP, probably established connections that break because of the roaming. That is harmless, and for cellular (public) IP you can filter that out with the valid-user acl, but if you have multiple internal IP spaces that can be used on the same SSID, that will not help you.

Also check that VLAN Mobility (under the virtual-ap wlan profile, advanced) is disabled. That feature may allow clients to hop to a different VLAN by just using the IP address in another VLAN, but you should then see in 'show ap association' that the client is in that other VLAN.

Summary:

• change to Aruba-User-VLAN assignment instead of role-based VLAN, if possible.
• validate in which VLAN the client actually is, if it has multiple IPs, one is in the assigned VLAN, and client does not have connectivity issues, there should not be an issue.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

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: Mar 12, 2024 09:09 AM
From: thisisrich
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

Hi,

In the  "Wireless LAN -> Virtual AP -> Beest" profile (Beest being the SSID of concern):

• Preserve Client VLAN is NOT checked
• VLAN Mobility is NOT checked

"Cellular handoff assist" and "Mobile IP" are checked, and I have no idea if that has any bearing on anything here.

After discovering that the VLANs were no longer being assigned with any consistency, I added the Aruba-User-Vlan attribute in the RADIUS server.  For each of the matching RADIUS connection policies that returns an Aruba-User-Role, I added the appropriately matching Aruba-User-Vlan attribute.  Later, I discovered that the Aruba controller does not just magically notice and apply this setting, but rather one must instruct the controller to read the attribute and apply it appropriately.

I believe this looks about right:

*[mm] #show aaa derivation-rules server-group Beest_dot1_svg
Server Group
------------
Name   Inservice  trim-FQDN  match-FQDN
----   ---------  ---------  ----------
jesse  Yes        No          

Server Rule Table
-----------------
Priority  Attribute        Operation  Operand/Group  Action    Value  Total Hits  New Hits  Description   
--------  ---------        ---------  -------------  ------    -----  ----------  --------  -----------   
1         Aruba-User-Role  value-of                  set role         0           0                        
2         Aruba-User-Vlan  value-of                  set vlan         270         267                      

Rule Entries: 2

Last night, I cleared the leases in our DHCP server, and deleted the users from the controller (aaa user delete...)

Right now, out of 130 users currently in the "MS_Students" role, who should all be in VLAN 80, a quick count shows that 52 of them are in the wrong VLAN.

There are currently 105 users in the "US_Students" role, who should all be in VLAN 72, but 20 of them are in the wrong VLAN.

I don't understand why it works most, but not all of the time.  I turned on user-debug logging for a handful of mac addresses in the same role, some that were in the correct VLAN, and some that weren't, but the results seem to be bit much to paste here, especially since I don't really know what lines might be most relevant.

In the time it has taken to type this, the number of US_Students users has risen to 118, and the number of those in the wrong VLAN has risen to 24.

I notice that there is a setting "Enforce user vlan for open stations" in the ssid-profile, which is currently disabled, and it is unclear what VLAN it would enforce (default, server derived, or role derived).  Would that help, or is that something different?

Many thanks in advance,

-rich

Original Message:
Sent: Mar 13, 2024 05:00 AM
From: Herman Robers
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

You may try to return both Aruba-User-Role and Aruba-User-VLAN as separate RADIUS return attributes during the authentication instead of assigning the VLAN by role to see if that improves.

What you can do to get rid of the double IP addresses is 'aaa user delete all' on the controller CLI to get rid of all 'stale' user entries. If the wrong IP addresses then re-appear, there may be something different wrong. Further, with 'show ap association' you can see the actual VLAN assigned to this user, where it's more important that you see the correct VLAN there. If a client uses an old IP address (but in the assigned VLAN), that IP address will show up under the client, but the client will not be able to communicate (with that IP) as it's in the wrong VLAN. Sometimes you may see IP addresses from cellular networks show up in the controller for devices that when roaming from cellular to WLAN, it still sends some traffic with the cellular IP, probably established connections that break because of the roaming. That is harmless, and for cellular (public) IP you can filter that out with the valid-user acl, but if you have multiple internal IP spaces that can be used on the same SSID, that will not help you.

Also check that VLAN Mobility (under the virtual-ap wlan profile, advanced) is disabled. That feature may allow clients to hop to a different VLAN by just using the IP address in another VLAN, but you should then see in 'show ap association' that the client is in that other VLAN.

Summary:

• change to Aruba-User-VLAN assignment instead of role-based VLAN, if possible.
• validate in which VLAN the client actually is, if it has multiple IPs, one is in the assigned VLAN, and client does not have connectivity issues, there should not be an issue.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

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: Mar 12, 2024 09:09 AM
From: thisisrich
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

Hi,

In the  "Wireless LAN -> Virtual AP -> Beest" profile (Beest being the SSID of concern):

• Preserve Client VLAN is NOT checked
• VLAN Mobility is NOT checked

"Cellular handoff assist" and "Mobile IP" are checked, and I have no idea if that has any bearing on anything here.

After discovering that the VLANs were no longer being assigned with any consistency, I added the Aruba-User-Vlan attribute in the RADIUS server.  For each of the matching RADIUS connection policies that returns an Aruba-User-Role, I added the appropriately matching Aruba-User-Vlan attribute.  Later, I discovered that the Aruba controller does not just magically notice and apply this setting, but rather one must instruct the controller to read the attribute and apply it appropriately.

I believe this looks about right:

*[mm] #show aaa derivation-rules server-group Beest_dot1_svg
Server Group
------------
Name   Inservice  trim-FQDN  match-FQDN
----   ---------  ---------  ----------
jesse  Yes        No          

Server Rule Table
-----------------
Priority  Attribute        Operation  Operand/Group  Action    Value  Total Hits  New Hits  Description   
--------  ---------        ---------  -------------  ------    -----  ----------  --------  -----------   
1         Aruba-User-Role  value-of                  set role         0           0                        
2         Aruba-User-Vlan  value-of                  set vlan         270         267                      

Rule Entries: 2

Last night, I cleared the leases in our DHCP server, and deleted the users from the controller (aaa user delete...)

Right now, out of 130 users currently in the "MS_Students" role, who should all be in VLAN 80, a quick count shows that 52 of them are in the wrong VLAN.

There are currently 105 users in the "US_Students" role, who should all be in VLAN 72, but 20 of them are in the wrong VLAN.

I don't understand why it works most, but not all of the time.  I turned on user-debug logging for a handful of mac addresses in the same role, some that were in the correct VLAN, and some that weren't, but the results seem to be bit much to paste here, especially since I don't really know what lines might be most relevant.

In the time it has taken to type this, the number of US_Students users has risen to 118, and the number of those in the wrong VLAN has risen to 24.

I notice that there is a setting "Enforce user vlan for open stations" in the ssid-profile, which is currently disabled, and it is unclear what VLAN it would enforce (default, server derived, or role derived).  Would that help, or is that something different?

Many thanks in advance,

-rich

You may try to return both Aruba-User-Role and Aruba-User-VLAN as separate RADIUS return attributes during the authentication instead of assigning the VLAN by role to see if that improves.

What you can do to get rid of the double IP addresses is 'aaa user delete all' on the controller CLI to get rid of all 'stale' user entries. If the wrong IP addresses then re-appear, there may be something different wrong. Further, with 'show ap association' you can see the actual VLAN assigned to this user, where it's more important that you see the correct VLAN there. If a client uses an old IP address (but in the assigned VLAN), that IP address will show up under the client, but the client will not be able to communicate (with that IP) as it's in the wrong VLAN. Sometimes you may see IP addresses from cellular networks show up in the controller for devices that when roaming from cellular to WLAN, it still sends some traffic with the cellular IP, probably established connections that break because of the roaming. That is harmless, and for cellular (public) IP you can filter that out with the valid-user acl, but if you have multiple internal IP spaces that can be used on the same SSID, that will not help you.

Also check that VLAN Mobility (under the virtual-ap wlan profile, advanced) is disabled. That feature may allow clients to hop to a different VLAN by just using the IP address in another VLAN, but you should then see in 'show ap association' that the client is in that other VLAN.

Summary:

• change to Aruba-User-VLAN assignment instead of role-based VLAN, if possible.
• validate in which VLAN the client actually is, if it has multiple IPs, one is in the assigned VLAN, and client does not have connectivity issues, there should not be an issue.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

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: Mar 12, 2024 09:09 AM
From: thisisrich
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

From the CLI of a controller, run "show user <IP address of user>" and in the information there will be a few useful returns.

Role: <role> (how: <description of how role is derived>), ACL: 99/0
Authentication: Yes, status: started, method: MAC, protocol: PAP, server: <servername>
Authentication Servers: dot1x authserver: , mac authserver: <servername>
...

Role Derivation: <role derivation method>
VLAN Derivation: <VLAN derivation method>

Hi,

In the  "Wireless LAN -> Virtual AP -> Beest" profile (Beest being the SSID of concern):

• Preserve Client VLAN is NOT checked
• VLAN Mobility is NOT checked

"Cellular handoff assist" and "Mobile IP" are checked, and I have no idea if that has any bearing on anything here.

After discovering that the VLANs were no longer being assigned with any consistency, I added the Aruba-User-Vlan attribute in the RADIUS server.  For each of the matching RADIUS connection policies that returns an Aruba-User-Role, I added the appropriately matching Aruba-User-Vlan attribute.  Later, I discovered that the Aruba controller does not just magically notice and apply this setting, but rather one must instruct the controller to read the attribute and apply it appropriately.

I believe this looks about right:

*[mm] #show aaa derivation-rules server-group Beest_dot1_svg
Server Group
------------
Name   Inservice  trim-FQDN  match-FQDN
----   ---------  ---------  ----------
jesse  Yes        No          

Server Rule Table
-----------------
Priority  Attribute        Operation  Operand/Group  Action    Value  Total Hits  New Hits  Description   
--------  ---------        ---------  -------------  ------    -----  ----------  --------  -----------   
1         Aruba-User-Role  value-of                  set role         0           0                        
2         Aruba-User-Vlan  value-of                  set vlan         270         267                      

Rule Entries: 2

Last night, I cleared the leases in our DHCP server, and deleted the users from the controller (aaa user delete...)

Right now, out of 130 users currently in the "MS_Students" role, who should all be in VLAN 80, a quick count shows that 52 of them are in the wrong VLAN.

There are currently 105 users in the "US_Students" role, who should all be in VLAN 72, but 20 of them are in the wrong VLAN.

I don't understand why it works most, but not all of the time.  I turned on user-debug logging for a handful of mac addresses in the same role, some that were in the correct VLAN, and some that weren't, but the results seem to be bit much to paste here, especially since I don't really know what lines might be most relevant.

In the time it has taken to type this, the number of US_Students users has risen to 118, and the number of those in the wrong VLAN has risen to 24.

I notice that there is a setting "Enforce user vlan for open stations" in the ssid-profile, which is currently disabled, and it is unclear what VLAN it would enforce (default, server derived, or role derived).  Would that help, or is that something different?

Many thanks in advance,

-rich

You may try to return both Aruba-User-Role and Aruba-User-VLAN as separate RADIUS return attributes during the authentication instead of assigning the VLAN by role to see if that improves.

What you can do to get rid of the double IP addresses is 'aaa user delete all' on the controller CLI to get rid of all 'stale' user entries. If the wrong IP addresses then re-appear, there may be something different wrong. Further, with 'show ap association' you can see the actual VLAN assigned to this user, where it's more important that you see the correct VLAN there. If a client uses an old IP address (but in the assigned VLAN), that IP address will show up under the client, but the client will not be able to communicate (with that IP) as it's in the wrong VLAN. Sometimes you may see IP addresses from cellular networks show up in the controller for devices that when roaming from cellular to WLAN, it still sends some traffic with the cellular IP, probably established connections that break because of the roaming. That is harmless, and for cellular (public) IP you can filter that out with the valid-user acl, but if you have multiple internal IP spaces that can be used on the same SSID, that will not help you.

Also check that VLAN Mobility (under the virtual-ap wlan profile, advanced) is disabled. That feature may allow clients to hop to a different VLAN by just using the IP address in another VLAN, but you should then see in 'show ap association' that the client is in that other VLAN.

Summary:

• change to Aruba-User-VLAN assignment instead of role-based VLAN, if possible.
• validate in which VLAN the client actually is, if it has multiple IPs, one is in the assigned VLAN, and client does not have connectivity issues, there should not be an issue.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

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: Mar 12, 2024 09:09 AM
From: thisisrich
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

Hi, 

As requested, a "show user" for a user who is in the wrong VLAN:

*[mynode] #show user ip 192.168.67.186
...

Name: [redacted], IP: 192.168.67.186, MAC: 0a:1c:2a:7b:1e:9f, Age: 00:00:14
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 64, Current: 64 vlan-how: 17 DP assigned vlan:0

VLAN is supposed to be 72. 

And, a "show user" for a user in the correct VLAN:

Name: [other redacted], IP: 192.168.74.48, MAC: 1e:9b:3c:21:f7:c6, Age: 00:00:38
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 72, Current: 72 vlan-how: 17 DP assigned vlan:0

The VLAN configured for the role is 72, and the Aruba-User-Vlan from the RADIUS server is 72.

From "show running-config":

aaa server-group "Beest_dot1_svg"
    auth-server jesse position 1
    set role condition Aruba-User-Role value-of
    set vlan condition Aruba-User-Vlan value-of
!

...

user-role US_Students              
   vlan 72
   access-list session global-sacl
   access-list session apprf-us_students-sacl
   access-list session US_Students
!

Again, the role is set correctly every time, for every user that connects.  The problem is just the VLAN.  The addition of the Aruba-User-Vlan was an attempt to correct the issue by adding another pointer to the correct VLAN that would hopefully overrule whatever process that is currently putting a percentage of users into the wrong VLAN. 

Annoyingly, in Active Directory, I can switch my user account between the various user groups, and I am placed in the correct VLAN every time.  Other than that, there seems to be little consistency in which users are misplaced into the wrong VLAN, beyond the approximate percentage of users affected.

I feel like I am missing something obvious, but I don't know what.

Also, it's worth a mention that I had my timeline wrong.  According to some additional log files, this issue definitely predated the aforementioned OS upgrade, so I have even less idea what went wrong.

-rich

From the CLI of a controller, run "show user <IP address of user>" and in the information there will be a few useful returns.

Role: <role> (how: <description of how role is derived>), ACL: 99/0
Authentication: Yes, status: started, method: MAC, protocol: PAP, server: <servername>
Authentication Servers: dot1x authserver: , mac authserver: <servername>
...

Role Derivation: <role derivation method>
VLAN Derivation: <VLAN derivation method>

Hi,

In the  "Wireless LAN -> Virtual AP -> Beest" profile (Beest being the SSID of concern):

• Preserve Client VLAN is NOT checked
• VLAN Mobility is NOT checked

"Cellular handoff assist" and "Mobile IP" are checked, and I have no idea if that has any bearing on anything here.

After discovering that the VLANs were no longer being assigned with any consistency, I added the Aruba-User-Vlan attribute in the RADIUS server.  For each of the matching RADIUS connection policies that returns an Aruba-User-Role, I added the appropriately matching Aruba-User-Vlan attribute.  Later, I discovered that the Aruba controller does not just magically notice and apply this setting, but rather one must instruct the controller to read the attribute and apply it appropriately.

I believe this looks about right:

*[mm] #show aaa derivation-rules server-group Beest_dot1_svg
Server Group
------------
Name   Inservice  trim-FQDN  match-FQDN
----   ---------  ---------  ----------
jesse  Yes        No          

Server Rule Table
-----------------
Priority  Attribute        Operation  Operand/Group  Action    Value  Total Hits  New Hits  Description   
--------  ---------        ---------  -------------  ------    -----  ----------  --------  -----------   
1         Aruba-User-Role  value-of                  set role         0           0                        
2         Aruba-User-Vlan  value-of                  set vlan         270         267                      

Rule Entries: 2

Last night, I cleared the leases in our DHCP server, and deleted the users from the controller (aaa user delete...)

Right now, out of 130 users currently in the "MS_Students" role, who should all be in VLAN 80, a quick count shows that 52 of them are in the wrong VLAN.

There are currently 105 users in the "US_Students" role, who should all be in VLAN 72, but 20 of them are in the wrong VLAN.

I don't understand why it works most, but not all of the time.  I turned on user-debug logging for a handful of mac addresses in the same role, some that were in the correct VLAN, and some that weren't, but the results seem to be bit much to paste here, especially since I don't really know what lines might be most relevant.

In the time it has taken to type this, the number of US_Students users has risen to 118, and the number of those in the wrong VLAN has risen to 24.

I notice that there is a setting "Enforce user vlan for open stations" in the ssid-profile, which is currently disabled, and it is unclear what VLAN it would enforce (default, server derived, or role derived).  Would that help, or is that something different?

Many thanks in advance,

-rich

You may try to return both Aruba-User-Role and Aruba-User-VLAN as separate RADIUS return attributes during the authentication instead of assigning the VLAN by role to see if that improves.

What you can do to get rid of the double IP addresses is 'aaa user delete all' on the controller CLI to get rid of all 'stale' user entries. If the wrong IP addresses then re-appear, there may be something different wrong. Further, with 'show ap association' you can see the actual VLAN assigned to this user, where it's more important that you see the correct VLAN there. If a client uses an old IP address (but in the assigned VLAN), that IP address will show up under the client, but the client will not be able to communicate (with that IP) as it's in the wrong VLAN. Sometimes you may see IP addresses from cellular networks show up in the controller for devices that when roaming from cellular to WLAN, it still sends some traffic with the cellular IP, probably established connections that break because of the roaming. That is harmless, and for cellular (public) IP you can filter that out with the valid-user acl, but if you have multiple internal IP spaces that can be used on the same SSID, that will not help you.

Also check that VLAN Mobility (under the virtual-ap wlan profile, advanced) is disabled. That feature may allow clients to hop to a different VLAN by just using the IP address in another VLAN, but you should then see in 'show ap association' that the client is in that other VLAN.

Summary:

• change to Aruba-User-VLAN assignment instead of role-based VLAN, if possible.
• validate in which VLAN the client actually is, if it has multiple IPs, one is in the assigned VLAN, and client does not have connectivity issues, there should not be an issue.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

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: Mar 12, 2024 09:09 AM
From: thisisrich
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

Hi, 

As requested, a "show user" for a user who is in the wrong VLAN:

*[mynode] #show user ip 192.168.67.186
...

Name: [redacted], IP: 192.168.67.186, MAC: 0a:1c:2a:7b:1e:9f, Age: 00:00:14
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 64, Current: 64 vlan-how: 17 DP assigned vlan:0

VLAN is supposed to be 72. 

And, a "show user" for a user in the correct VLAN:

Name: [other redacted], IP: 192.168.74.48, MAC: 1e:9b:3c:21:f7:c6, Age: 00:00:38
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 72, Current: 72 vlan-how: 17 DP assigned vlan:0

The VLAN configured for the role is 72, and the Aruba-User-Vlan from the RADIUS server is 72.

From "show running-config":

aaa server-group "Beest_dot1_svg"
    auth-server jesse position 1
    set role condition Aruba-User-Role value-of
    set vlan condition Aruba-User-Vlan value-of
!

...

user-role US_Students              
   vlan 72
   access-list session global-sacl
   access-list session apprf-us_students-sacl
   access-list session US_Students
!

Again, the role is set correctly every time, for every user that connects.  The problem is just the VLAN.  The addition of the Aruba-User-Vlan was an attempt to correct the issue by adding another pointer to the correct VLAN that would hopefully overrule whatever process that is currently putting a percentage of users into the wrong VLAN. 

Annoyingly, in Active Directory, I can switch my user account between the various user groups, and I am placed in the correct VLAN every time.  Other than that, there seems to be little consistency in which users are misplaced into the wrong VLAN, beyond the approximate percentage of users affected.

I feel like I am missing something obvious, but I don't know what.

Also, it's worth a mention that I had my timeline wrong.  According to some additional log files, this issue definitely predated the aforementioned OS upgrade, so I have even less idea what went wrong.

-rich

From the CLI of a controller, run "show user <IP address of user>" and in the information there will be a few useful returns.

Role: <role> (how: <description of how role is derived>), ACL: 99/0
Authentication: Yes, status: started, method: MAC, protocol: PAP, server: <servername>
Authentication Servers: dot1x authserver: , mac authserver: <servername>
...

Role Derivation: <role derivation method>
VLAN Derivation: <VLAN derivation method>

Hi,

In the  "Wireless LAN -> Virtual AP -> Beest" profile (Beest being the SSID of concern):

• Preserve Client VLAN is NOT checked
• VLAN Mobility is NOT checked

"Cellular handoff assist" and "Mobile IP" are checked, and I have no idea if that has any bearing on anything here.

After discovering that the VLANs were no longer being assigned with any consistency, I added the Aruba-User-Vlan attribute in the RADIUS server.  For each of the matching RADIUS connection policies that returns an Aruba-User-Role, I added the appropriately matching Aruba-User-Vlan attribute.  Later, I discovered that the Aruba controller does not just magically notice and apply this setting, but rather one must instruct the controller to read the attribute and apply it appropriately.

I believe this looks about right:

*[mm] #show aaa derivation-rules server-group Beest_dot1_svg
Server Group
------------
Name   Inservice  trim-FQDN  match-FQDN
----   ---------  ---------  ----------
jesse  Yes        No          

Server Rule Table
-----------------
Priority  Attribute        Operation  Operand/Group  Action    Value  Total Hits  New Hits  Description   
--------  ---------        ---------  -------------  ------    -----  ----------  --------  -----------   
1         Aruba-User-Role  value-of                  set role         0           0                        
2         Aruba-User-Vlan  value-of                  set vlan         270         267                      

Rule Entries: 2

Last night, I cleared the leases in our DHCP server, and deleted the users from the controller (aaa user delete...)

Right now, out of 130 users currently in the "MS_Students" role, who should all be in VLAN 80, a quick count shows that 52 of them are in the wrong VLAN.

There are currently 105 users in the "US_Students" role, who should all be in VLAN 72, but 20 of them are in the wrong VLAN.

I don't understand why it works most, but not all of the time.  I turned on user-debug logging for a handful of mac addresses in the same role, some that were in the correct VLAN, and some that weren't, but the results seem to be bit much to paste here, especially since I don't really know what lines might be most relevant.

In the time it has taken to type this, the number of US_Students users has risen to 118, and the number of those in the wrong VLAN has risen to 24.

I notice that there is a setting "Enforce user vlan for open stations" in the ssid-profile, which is currently disabled, and it is unclear what VLAN it would enforce (default, server derived, or role derived).  Would that help, or is that something different?

Many thanks in advance,

-rich

You may try to return both Aruba-User-Role and Aruba-User-VLAN as separate RADIUS return attributes during the authentication instead of assigning the VLAN by role to see if that improves.

What you can do to get rid of the double IP addresses is 'aaa user delete all' on the controller CLI to get rid of all 'stale' user entries. If the wrong IP addresses then re-appear, there may be something different wrong. Further, with 'show ap association' you can see the actual VLAN assigned to this user, where it's more important that you see the correct VLAN there. If a client uses an old IP address (but in the assigned VLAN), that IP address will show up under the client, but the client will not be able to communicate (with that IP) as it's in the wrong VLAN. Sometimes you may see IP addresses from cellular networks show up in the controller for devices that when roaming from cellular to WLAN, it still sends some traffic with the cellular IP, probably established connections that break because of the roaming. That is harmless, and for cellular (public) IP you can filter that out with the valid-user acl, but if you have multiple internal IP spaces that can be used on the same SSID, that will not help you.

Also check that VLAN Mobility (under the virtual-ap wlan profile, advanced) is disabled. That feature may allow clients to hop to a different VLAN by just using the IP address in another VLAN, but you should then see in 'show ap association' that the client is in that other VLAN.

Summary:

• change to Aruba-User-VLAN assignment instead of role-based VLAN, if possible.
• validate in which VLAN the client actually is, if it has multiple IPs, one is in the assigned VLAN, and client does not have connectivity issues, there should not be an issue.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

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: Mar 12, 2024 09:09 AM
From: thisisrich
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

Check again which radius attributes you are returning.

Here you set user role and VLAN ID with radius attributes.

Aruba-User-VLAN overwrite the VLAN from the user role, the controller says that the user is in VLAN 64.

*[mynode] #show user ip 192.168.67.186
...

Name: [redacted], IP: 192.168.67.186, MAC: 0a:1c:2a:7b:1e:9f, Age: 00:00:14
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 64, Current: 64 vlan-how: 17 DP assigned vlan:0

Here the user role and VLAN ID are also assigned via the Radius attribute.

The user is in VLAN 72, the default VLAN ID 64 has been overwritten.

Name: [other redacted], IP: 192.168.74.48, MAC: 1e:9b:3c:21:f7:c6, Age: 00:00:38
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 72, Current: 72 vlan-how: 17 DP assigned vlan:0

You write that some users remain in the VLAN that is designated in the WLAN SSID. This is what happens when you return an incorrect user role. A role that does not exist or with incorrect upper-lower case.

Do you have multiple WLAN controllers? Check whether the role exists in each and has been spelled correctly.

Are you sure that the clients have obtained IP addresses from the DHCP server? You can also see this information in the "show user ip x.x.x.x" output.

Hi, 

As requested, a "show user" for a user who is in the wrong VLAN:

*[mynode] #show user ip 192.168.67.186
...

Name: [redacted], IP: 192.168.67.186, MAC: 0a:1c:2a:7b:1e:9f, Age: 00:00:14
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 64, Current: 64 vlan-how: 17 DP assigned vlan:0

VLAN is supposed to be 72. 

And, a "show user" for a user in the correct VLAN:

Name: [other redacted], IP: 192.168.74.48, MAC: 1e:9b:3c:21:f7:c6, Age: 00:00:38
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 72, Current: 72 vlan-how: 17 DP assigned vlan:0

The VLAN configured for the role is 72, and the Aruba-User-Vlan from the RADIUS server is 72.

From "show running-config":

aaa server-group "Beest_dot1_svg"
    auth-server jesse position 1
    set role condition Aruba-User-Role value-of
    set vlan condition Aruba-User-Vlan value-of
!

...

user-role US_Students              
   vlan 72
   access-list session global-sacl
   access-list session apprf-us_students-sacl
   access-list session US_Students
!

Again, the role is set correctly every time, for every user that connects.  The problem is just the VLAN.  The addition of the Aruba-User-Vlan was an attempt to correct the issue by adding another pointer to the correct VLAN that would hopefully overrule whatever process that is currently putting a percentage of users into the wrong VLAN. 

Annoyingly, in Active Directory, I can switch my user account between the various user groups, and I am placed in the correct VLAN every time.  Other than that, there seems to be little consistency in which users are misplaced into the wrong VLAN, beyond the approximate percentage of users affected.

I feel like I am missing something obvious, but I don't know what.

Also, it's worth a mention that I had my timeline wrong.  According to some additional log files, this issue definitely predated the aforementioned OS upgrade, so I have even less idea what went wrong.

-rich

From the CLI of a controller, run "show user <IP address of user>" and in the information there will be a few useful returns.

Role: <role> (how: <description of how role is derived>), ACL: 99/0
Authentication: Yes, status: started, method: MAC, protocol: PAP, server: <servername>
Authentication Servers: dot1x authserver: , mac authserver: <servername>
...

Role Derivation: <role derivation method>
VLAN Derivation: <VLAN derivation method>

Hi,

In the  "Wireless LAN -> Virtual AP -> Beest" profile (Beest being the SSID of concern):

• Preserve Client VLAN is NOT checked
• VLAN Mobility is NOT checked

"Cellular handoff assist" and "Mobile IP" are checked, and I have no idea if that has any bearing on anything here.

After discovering that the VLANs were no longer being assigned with any consistency, I added the Aruba-User-Vlan attribute in the RADIUS server.  For each of the matching RADIUS connection policies that returns an Aruba-User-Role, I added the appropriately matching Aruba-User-Vlan attribute.  Later, I discovered that the Aruba controller does not just magically notice and apply this setting, but rather one must instruct the controller to read the attribute and apply it appropriately.

I believe this looks about right:

*[mm] #show aaa derivation-rules server-group Beest_dot1_svg
Server Group
------------
Name   Inservice  trim-FQDN  match-FQDN
----   ---------  ---------  ----------
jesse  Yes        No          

Server Rule Table
-----------------
Priority  Attribute        Operation  Operand/Group  Action    Value  Total Hits  New Hits  Description   
--------  ---------        ---------  -------------  ------    -----  ----------  --------  -----------   
1         Aruba-User-Role  value-of                  set role         0           0                        
2         Aruba-User-Vlan  value-of                  set vlan         270         267                      

Rule Entries: 2

Last night, I cleared the leases in our DHCP server, and deleted the users from the controller (aaa user delete...)

Right now, out of 130 users currently in the "MS_Students" role, who should all be in VLAN 80, a quick count shows that 52 of them are in the wrong VLAN.

There are currently 105 users in the "US_Students" role, who should all be in VLAN 72, but 20 of them are in the wrong VLAN.

I don't understand why it works most, but not all of the time.  I turned on user-debug logging for a handful of mac addresses in the same role, some that were in the correct VLAN, and some that weren't, but the results seem to be bit much to paste here, especially since I don't really know what lines might be most relevant.

In the time it has taken to type this, the number of US_Students users has risen to 118, and the number of those in the wrong VLAN has risen to 24.

I notice that there is a setting "Enforce user vlan for open stations" in the ssid-profile, which is currently disabled, and it is unclear what VLAN it would enforce (default, server derived, or role derived).  Would that help, or is that something different?

Many thanks in advance,

-rich

You may try to return both Aruba-User-Role and Aruba-User-VLAN as separate RADIUS return attributes during the authentication instead of assigning the VLAN by role to see if that improves.

What you can do to get rid of the double IP addresses is 'aaa user delete all' on the controller CLI to get rid of all 'stale' user entries. If the wrong IP addresses then re-appear, there may be something different wrong. Further, with 'show ap association' you can see the actual VLAN assigned to this user, where it's more important that you see the correct VLAN there. If a client uses an old IP address (but in the assigned VLAN), that IP address will show up under the client, but the client will not be able to communicate (with that IP) as it's in the wrong VLAN. Sometimes you may see IP addresses from cellular networks show up in the controller for devices that when roaming from cellular to WLAN, it still sends some traffic with the cellular IP, probably established connections that break because of the roaming. That is harmless, and for cellular (public) IP you can filter that out with the valid-user acl, but if you have multiple internal IP spaces that can be used on the same SSID, that will not help you.

Also check that VLAN Mobility (under the virtual-ap wlan profile, advanced) is disabled. That feature may allow clients to hop to a different VLAN by just using the IP address in another VLAN, but you should then see in 'show ap association' that the client is in that other VLAN.

Summary:

• change to Aruba-User-VLAN assignment instead of role-based VLAN, if possible.
• validate in which VLAN the client actually is, if it has multiple IPs, one is in the assigned VLAN, and client does not have connectivity issues, there should not be an issue.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

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: Mar 12, 2024 09:09 AM
From: thisisrich
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

Hi,

Previously, the RADIUS server returned only the role name for the user, and the appropriate VLAN was specified in the Aruba Role definition:

user-role US_Students
    access-list session us_students
    access-list session students
    vlan 72
!
user-role MS_Students
    access-list session ms_students
    access-list session students
    vlan 80    
!

This is what stopped working.  Well, stopped working some of the time.  Previously, it was fairly flawless.  Then it wasn't.

Then, I added the Aruba-User-Vlan attribute to the RADIUS return, so any return for the "US_Students" role would include the appropriate VLAN also.  This did not fix the problem, but I then realized that the Aruba controller might not pay attention to any returned RADIUS attributes unless it was told to, so I added the derivation rules.

Unfortunately, this also did not change anything.  Every user that logs in always receives the correct role.  The Aruba controller has the correct VLAN in the Role definition., and with or without the RADIUS Aruba-User-Vlan attribute, a percentage of users are placed in the default VLAN, not the one they are supposed to be in.

I am currently running a packet capture on the RADIUS server to ensure that there isn't something truly odd happening, like one of the Network Connection Policies for one group returning the Aruba-User-Vlan attribute from one of the other Network Connection Policies, but that seems unlikely, and since I have returned the Aruba back to its original, pre-troubleshooting, "just give me the role name, please" config, I would imagine it would also be irrelevant.

The Good News™ is that we have spring break next week, which means I can really break things troubleshoot with reckless abandon.

On a side note, is there any reason not to go to ArubaOS 10.4.xxx ?

Thanks in advance,

-rich

Check again which radius attributes you are returning.

Here you set user role and VLAN ID with radius attributes.

Aruba-User-VLAN overwrite the VLAN from the user role, the controller says that the user is in VLAN 64.

*[mynode] #show user ip 192.168.67.186
...

Name: [redacted], IP: 192.168.67.186, MAC: 0a:1c:2a:7b:1e:9f, Age: 00:00:14
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 64, Current: 64 vlan-how: 17 DP assigned vlan:0

Here the user role and VLAN ID are also assigned via the Radius attribute.

The user is in VLAN 72, the default VLAN ID 64 has been overwritten.

Name: [other redacted], IP: 192.168.74.48, MAC: 1e:9b:3c:21:f7:c6, Age: 00:00:38
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 72, Current: 72 vlan-how: 17 DP assigned vlan:0

You write that some users remain in the VLAN that is designated in the WLAN SSID. This is what happens when you return an incorrect user role. A role that does not exist or with incorrect upper-lower case.

Do you have multiple WLAN controllers? Check whether the role exists in each and has been spelled correctly.

Are you sure that the clients have obtained IP addresses from the DHCP server? You can also see this information in the "show user ip x.x.x.x" output.

Hi, 

As requested, a "show user" for a user who is in the wrong VLAN:

*[mynode] #show user ip 192.168.67.186
...

Name: [redacted], IP: 192.168.67.186, MAC: 0a:1c:2a:7b:1e:9f, Age: 00:00:14
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 64, Current: 64 vlan-how: 17 DP assigned vlan:0

VLAN is supposed to be 72. 

And, a "show user" for a user in the correct VLAN:

Name: [other redacted], IP: 192.168.74.48, MAC: 1e:9b:3c:21:f7:c6, Age: 00:00:38
Role: US_Students (how: ROLE_DERIVATION_DOT1X_VSA), ACL: 134/0
Authentication: Yes, status: successful, method: 802.1x, protocol: EAP-PEAP, server: jesse
Authentication Servers: dot1x authserver: jesse, mac authserver:
Bandwidth = No Limit
Bandwidth = No Limit
Role Derivation: ROLE_DERIVATION_DOT1X_VSA
VLAN Derivation: Dot1x Aruba VSA
Idle timeout (global): 300 seconds, Age: 00:00:00
Mobility state: Wireless, HA: Yes, Proxy ARP: No, Roaming: No Tunnel ID: 0 L3 Mob: 0
Flags: internal=0, trusted_ap=0, l3auth=0, mba=0, vpnflags=0, u_stm_ageout=1
Flags: innerip=0, outerip=0, vpn_outer_ind:0, download=1, wispr=0
IP User termcause: 0
phy_type: 5GHz-HE-40, l3 reauth: 0, BW Contract: up:0 down:0, user-how: 14
Vlan default: 64, Assigned: 72, Current: 72 vlan-how: 17 DP assigned vlan:0

The VLAN configured for the role is 72, and the Aruba-User-Vlan from the RADIUS server is 72.

From "show running-config":

aaa server-group "Beest_dot1_svg"
    auth-server jesse position 1
    set role condition Aruba-User-Role value-of
    set vlan condition Aruba-User-Vlan value-of
!

...

user-role US_Students              
   vlan 72
   access-list session global-sacl
   access-list session apprf-us_students-sacl
   access-list session US_Students
!

Again, the role is set correctly every time, for every user that connects.  The problem is just the VLAN.  The addition of the Aruba-User-Vlan was an attempt to correct the issue by adding another pointer to the correct VLAN that would hopefully overrule whatever process that is currently putting a percentage of users into the wrong VLAN. 

Annoyingly, in Active Directory, I can switch my user account between the various user groups, and I am placed in the correct VLAN every time.  Other than that, there seems to be little consistency in which users are misplaced into the wrong VLAN, beyond the approximate percentage of users affected.

I feel like I am missing something obvious, but I don't know what.

Also, it's worth a mention that I had my timeline wrong.  According to some additional log files, this issue definitely predated the aforementioned OS upgrade, so I have even less idea what went wrong.

-rich

From the CLI of a controller, run "show user <IP address of user>" and in the information there will be a few useful returns.

Role: <role> (how: <description of how role is derived>), ACL: 99/0
Authentication: Yes, status: started, method: MAC, protocol: PAP, server: <servername>
Authentication Servers: dot1x authserver: , mac authserver: <servername>
...

Role Derivation: <role derivation method>
VLAN Derivation: <VLAN derivation method>

Hi,

In the  "Wireless LAN -> Virtual AP -> Beest" profile (Beest being the SSID of concern):

• Preserve Client VLAN is NOT checked
• VLAN Mobility is NOT checked

"Cellular handoff assist" and "Mobile IP" are checked, and I have no idea if that has any bearing on anything here.

After discovering that the VLANs were no longer being assigned with any consistency, I added the Aruba-User-Vlan attribute in the RADIUS server.  For each of the matching RADIUS connection policies that returns an Aruba-User-Role, I added the appropriately matching Aruba-User-Vlan attribute.  Later, I discovered that the Aruba controller does not just magically notice and apply this setting, but rather one must instruct the controller to read the attribute and apply it appropriately.

I believe this looks about right:

*[mm] #show aaa derivation-rules server-group Beest_dot1_svg
Server Group
------------
Name   Inservice  trim-FQDN  match-FQDN
----   ---------  ---------  ----------
jesse  Yes        No          

Server Rule Table
-----------------
Priority  Attribute        Operation  Operand/Group  Action    Value  Total Hits  New Hits  Description   
--------  ---------        ---------  -------------  ------    -----  ----------  --------  -----------   
1         Aruba-User-Role  value-of                  set role         0           0                        
2         Aruba-User-Vlan  value-of                  set vlan         270         267                      

Rule Entries: 2

Last night, I cleared the leases in our DHCP server, and deleted the users from the controller (aaa user delete...)

Right now, out of 130 users currently in the "MS_Students" role, who should all be in VLAN 80, a quick count shows that 52 of them are in the wrong VLAN.

There are currently 105 users in the "US_Students" role, who should all be in VLAN 72, but 20 of them are in the wrong VLAN.

I don't understand why it works most, but not all of the time.  I turned on user-debug logging for a handful of mac addresses in the same role, some that were in the correct VLAN, and some that weren't, but the results seem to be bit much to paste here, especially since I don't really know what lines might be most relevant.

In the time it has taken to type this, the number of US_Students users has risen to 118, and the number of those in the wrong VLAN has risen to 24.

I notice that there is a setting "Enforce user vlan for open stations" in the ssid-profile, which is currently disabled, and it is unclear what VLAN it would enforce (default, server derived, or role derived).  Would that help, or is that something different?

Many thanks in advance,

-rich

You may try to return both Aruba-User-Role and Aruba-User-VLAN as separate RADIUS return attributes during the authentication instead of assigning the VLAN by role to see if that improves.

What you can do to get rid of the double IP addresses is 'aaa user delete all' on the controller CLI to get rid of all 'stale' user entries. If the wrong IP addresses then re-appear, there may be something different wrong. Further, with 'show ap association' you can see the actual VLAN assigned to this user, where it's more important that you see the correct VLAN there. If a client uses an old IP address (but in the assigned VLAN), that IP address will show up under the client, but the client will not be able to communicate (with that IP) as it's in the wrong VLAN. Sometimes you may see IP addresses from cellular networks show up in the controller for devices that when roaming from cellular to WLAN, it still sends some traffic with the cellular IP, probably established connections that break because of the roaming. That is harmless, and for cellular (public) IP you can filter that out with the valid-user acl, but if you have multiple internal IP spaces that can be used on the same SSID, that will not help you.

Also check that VLAN Mobility (under the virtual-ap wlan profile, advanced) is disabled. That feature may allow clients to hop to a different VLAN by just using the IP address in another VLAN, but you should then see in 'show ap association' that the client is in that other VLAN.

Summary:

• change to Aruba-User-VLAN assignment instead of role-based VLAN, if possible.
• validate in which VLAN the client actually is, if it has multiple IPs, one is in the assigned VLAN, and client does not have connectivity issues, there should not be an issue.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

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: Mar 12, 2024 09:09 AM
From: thisisrich
Subject: Role based VLAN assignment stopped working after an updating Aruba OS on 7205

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich

Hi,

We have an Aruba 7205 based WiFi network, authenticating through a Windows RADIUS server.  We have several Roles, each with a different VLAN assigned.

When I check the list of currently connected users in the Dashboard, I can see that all of the users have the correct role assigned, but many (not all) are in the wrong VLAN.

If I hover my mouse over the IP number of a user placed in the incorrect VLAN, a small text box appears with the IP number from the incorrect VLAN, along with a different IP that would be in the correct VLAN.  The correct IP is otherwise unknown to the system, and if I sort the client list by MAC address, there is only the one (incorrect VLAN) IP.

This is a network for a private school.  We have one SSID that WPA2/3 Enterprise authenticates against a Windows RADIUS server.  The RADIUS server provides the role name to the Aruba controller correctly, as the Aruba controller's Dashboard demonstrates.  We use the roles to dictate which VLAN our users land in, and our content filter applies different rules based on the IP range.  

The problem is that the Aruba controller doesn't put a percentage of the users into the correct VLAN, but keeps them in the "default" VLAN designated in the WLAN SSID configuration.

While it might be coincidence, it is worth noting that I only noticed this after upgrading from ArubaOS 8.11.2.1 to ArubaOS 8.11.2.2. 

Many thanks in advance,

-rich