VLAN steering does not get new VLAN IP address

  • 1
  • Question
  • Updated 5 years ago
  • Answered
We are trying to use peap certificates and RADIUS attributes to direct groups of users to specific VLAN's using the same SSID. Staff to get a more open VLAN and Students to get a more restrictive VLAN. When logging off a student and logging on to a staff account, (or vise-versa) the IP address is not refreshed, if we run ipconfig /release and ipconfig /renew we get the correct VLAN IP address.

We have looked at ip-helper settings and they appear to be correct. I assume we would not get the correct IP address using ipconfig /release /renew if this was the problem. As it appears to me that the VLAN attribute does get assigned to the client just not the new VLAN IP address.

Is there something else I need to check or do to make this work?
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
  • frustrated

Posted 5 years ago

  • 1
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
Aerohive APs cache information about a station (including assigned user profile attribute) for a period. This cached information helps speed up the processes of roaming and reassociation/re-authentication to the network if the device briefly disconnects.

If you are logging out as staff and logging in as a student immediately, it is likely the client records are still in the cache. The relevant cache setting in this case is the Inactive client age-out setting, which you can find under the Advanced settings option for an 802.1X/EAP-secured SSID. By default, this ageout setting is set for 5 minutes, but you can tune the setting down to as low as 1 minute if you prefer.

You will also find other cache update settings for roaming cache and local cache as well. The help file for all these settings can be found here.

As part of your testing, you can manually clear the cache on an AP by running these commands:
clear auth station
clear auth roaming-cache
clear auth local-cache
Photo of Jonathan Hurtt

Jonathan Hurtt

  • 98 Posts
  • 48 Reply Likes
If these are domain computers, another idea is to set up User and Computer Authentication within the domain policy, so that once the staff logs out the computer will login with machine credentials and possibly give a different result.
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
Hello Jonathan, I believe I will need to setup computer authentication. I have looked at the network policies and cannot see how to make it happen. Can you point me to a guided setup?

We were also having problems with certificates. The problem was the physical box we were using as the aerohive radius server. We configured a brand new AP330.
We now have our certificates working and we do see through the client monitor that the authentication is using SSL and PEAP encryption, we see the 4 way handshake.

We also dropped the client age-out to 1 minute. This did not make any difference. To the VLAN steering problems we have.
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
I have just been shown a 5.1r1 hive user profile that is using VLAN steering. There is a different line shown in the top section of 5.1r1 but my 6.1r1 hive (bottom section) that does not show this information.



is there an equivalent option is 6.1r1?
Photo of Jonathan Hurtt

Jonathan Hurtt

  • 98 Posts
  • 48 Reply Likes
Computer Authentication will be configured on the Client's Supplicant (or can be configured through Group Policy). Setting this up will depend on the type of client.

As for the difference between the User Profile VLAN/Network Assignment in 5.1r1 and 6.1r1. In 5.1r1. we combined the VLAN and Network Configuration into one single object, and in 6.1r1 we made two different objects VLAN and Network. This allows for greater flexibility when configuring Router Network Polices. the VLAN-Only Assignment is the functional equivalent as Default VLAN.
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
Hello Jonathan,

I have reconfigured and can confirm that I have Computer authentication encrypted and I do get the computer VLAN address, when I monitor the client in AeroHive.

When I log on as a Student. I get an encrypted authentication and get the Student VLAN. This is actually the same VLAN as the computer VLAN.

When I log on as a Staff member I get encrypted authentication and get the correct VLAN attribute but I get the same IP address from the student VLAN. Not an address from the Staff VLAN. Monitoring the clients shows the VLAN attribute has been assigned to the staff VLAN it has not been issued a staff VLAN IP address.

If I do an ipconfig /release and ipconfig /renew I get the correct Staff VLAN IP address.

Now when I log off the IP address stays on the Staff VLAN and not the computer VLAN.

If I setup 2 different SSID's and assign the staff to one SSID and the Students to the other and switch between SSID's. I do get issued the correct VLAN attribute and the correct IP address. Is there a limitation that makes VLAN steering on the same SSID impossible?
Photo of Jonathan Hurtt

Jonathan Hurtt

  • 98 Posts
  • 48 Reply Likes
Michael,

Have changed the settings that Andrew suggested? Also what is your DHCP lease time?
Photo of Andrew Garcia

Andrew Garcia, Official Rep

  • 368 Posts
  • 120 Reply Likes
I think we need to back up a little here and talk about your config and devices.
- What client device/OS are you testing with that is exhibiting this behavior?
- What wireless adapter is in the device (if it is a laptop?)
- Can you replicate this behavior with other clients? Other types of clients?
- How are you switching users? Logging out of the operating system, or switching logins to the wireless network from within the same OS account? How much time lag are you leaving between logging out and logging back in?
- Have you looked at the command line of the AP to see if the correct VLAN is applied as soon as the second user logs in? You should be able to see the user attribute and VLAN.

I'm a little concerned that the client is not issuing a DHCP request when it switches users/VLAN. Can you perform a packet trace to see if the client is asking for a new address once it logs in as the second user?
Photo of Michael Drummond

Michael Drummond

  • 36 Posts
  • 0 Reply Likes
Hello Jonathan,

Yes I did drop the ageout setting to 1 minute. As shown in a post above.
We have a 7 day DHCP lease time. This is not affecting switching SSID's only affecting switching VLAN's in the same SSID.

I'm not sure where to run the command line commands.

Hello Andrew,

We are seeing this behaviour on Win7, Win8, MAC OS X, iOS, Android.
We are using DELL notebooks with Intel Centrino Ultimate-N 6300AGN,Intel Centrino Advanced-N 6230, Intel Centrino Advanced-N 6205 are some of the wifi cards/drivers.
iPhone, iPad, Samsung Galaxy S, Samsung Galaxy S2, Dell Slate ST, Windows Surface,

We have tried full reboot of the computer, log off and back on. To speed up testing we are switching from the same OS user account, we have not cached the username and password on the supplicant configuration, and credentials are asked for every time we reconnect to the SSID's. So we just disconnect from the SSID, wait the 1 minute for ageout, and reconnect using another users credentials.

Do I telnet/ssh to the IP address of the AP or the hivemanager computer or the radius ap? or all three? Or do I log onto the Linux box directly?

When monitoring the client from hivemanager we see a DHCP request as shown below. This is shown every time we switch user credentials on the same SSID and when we change SSID's.

07/25/2013 10:00:10 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS INFO station sent out DHCP REQUEST message
07/25/2013 10:00:10 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS INFO (122015)DHCP server sent out DHCP ACKNOWLEDGE message to station
07/25/2013 10:00:10 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS BASIC (122016)DHCP session completed for station
07/25/2013 10:00:10 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS BASIC (122017)IP 192.168.18.159 assigned for station

when we run ipconfig /release, ipconfig /renew we get a DHCP Discover as show below. Also if we connect to a new SSID we get the following in client monitor.

07/25/2013 10:03:50 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS INFO (122599)station sent out DHCP DISCOVER message
07/25/2013 10:03:51 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS INFO (122600)DHCP server sent out DHCP OFFER message to station
07/25/2013 10:03:51 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS INFO (122601)station sent out DHCP REQUEST message
07/25/2013 10:03:51 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS INFO (122602)DHCP server sent out DHCP ACKNOWLEDGE message to station
07/25/2013 10:03:51 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS BASIC (122603)DHCP session completed for station
07/25/2013 10:03:51 AM 247703E77CEC 08EA448A5DE8 HiveAP-RADIUS BASIC (122604)IP 192.168.20.23 assigned for station

On the Active Client monitoring page of HiveManager we do see the authenticated client getting the correct RADIUS attribute and correct VLAN id. But only get the correct IP when we run ipconfig /release, ipconfig /renew.

Is there a way that aerohive/group policy forces the client to do a DHCP discover?
Photo of Brian Ambler

Brian Ambler

  • 245 Posts
  • 126 Reply Likes
Hello Michael,

Would you be able to try the following steps and see if your client is still receiving the wrong IP address?

  1. Connect your client to the SSID as a Staff user

  2. Have your client disconnect from the SSID

  3. SSH into the AP to which your client is connected and run the following commands:


  • clear auth station

  • clear auth local-cache

  • clear auth roaming-cache


  • Have your client connect back to the SSID as a Student user and check the IP address it receives


  • If your client does receive the correct IP address after the above steps, then your client is likely being stored in the AP's roaming cache. the roaming cache was designed so that when a client roams to the next AP, it sends its PMK ID in the association request, which the AP uses to query its PMK ID list. If it finds a match, it uses that PMK to perform the four way handshake and establish a new PTK instead of having the client run through the whole 802.1X authentication for each roaming event.

    However, if your client disconnects and reconnects to the same AP within the period before the roaming cache ages out (the default is 60 minutes), it will also use the cached PMK on the AP rather than going through a full authentication event. This usually causes the client to receive the same IP address as it had before. This does cause issues when shared clients are used to switch between VLANs whereas a fresh client connecting to the SSID does not experience an issue.

    Obviously the easy solution is not to share machines between faculty and staff. However, if you will be using shared machines between Staff and Student users in your production environment, the workaround is to reduce the roaming cache ageout time. The lowest time period for which the roaming cache can set is 10 seconds, though setting it that low could impact users roaming between APs. To calculate the roaming cache timeout, multiply the Roaming Cache Update Interval by the Roaming Cache Ageout. In situations like these where using shared clients is mandatory, I usually recommend between 1 and 5 minutes, depending on how ofter users will be logging into the machine. For more information, see the help section on the Roaming Cache, which I have excerpted below:

    From the Help system regarding the Roaming Cache Settings:

    Roaming Cache Settings: When using 802.1X authentication, the RADIUS authentication server sends the wireless client (or supplicant) a master key from which the client derives a PMK (pairwise master key). Using the same computations as the client, the RADIUS server derives an identical PMK and sends that to the access point (authenticator). When using WPA/WPA2 PSK (Personal) for access security, the preshared key acts as the PMK.

    The client and access point then perform a four-way handshake, using the PMK to establish a PTK (pairwise transient key). Next, they use that PTK to encrypt unicast traffic between themselves. The access point also makes a GMK (group master key) from which it derives a GTK (group temporal key) for encrypting and decrypting broadcast and multicast traffic. Using the secure connection established for unicast traffic, the access point sends the GTK to the client.

    Every time a wireless client using 802.1X authentication sends an association request to an access point, it includes a PMK (pairwise master key) ID list. When a client associates with an access point initially, the list is empty. When the client roams and sends a reassociation request to a new access point, the PMK ID list can contain the PMK ID from the first association, a new PMK ID based in part on the MAC address of the new access point (which the client learned from its beacon), or another empty list. The new access point then searches its PMK ID list for a match with the PMK ID that the client sends. If it finds a match, it uses that PMK when performing another four-way handshake to establish a new PTK. If it does not find a match, then the client, access point, and authentication server must go through the entire 802.1X authentication sequence again.

    APs keep PMKs that their neighbors send them in their roaming cache. The following settings control how often Aerohive devices send roaming cache updates to their neighbors and when to age out and remove old entries from the roaming cache.

    Roaming Cache Update Interval: By default, an Aerohive AP sends updates to its neighbors about the clients currently associated with it every 60 seconds. The neighboring APs use this information to update their roaming caches—if necessary—with the most up-to-date client information from their neighboring APs. You can change the frequency for sending roaming cache updates to neighbors from 10 and 36,000 seconds (10 hours).

    Roaming Cache Ageout: By default, an Aerohive device removes an entry from its roaming cache if it is absent from 60 consecutive updates from a neighbor. You can change how many times an entry must be absent from a neighbor's updates before removing it from the roaming cache from just once to 1000 consecutive times.

  • To calculate the length of time required for a PMK to age out, multiply the update interval by the ageout value. Using the default settings 60 seconds (interval) x 60 (absences), a PMK ages out after 60 minutes.


  • You can modify the roaming cache settings here for an SSID, where they apply to clients that use this SSID, or at the hive level, where they apply to all clients. The following rules govern when one setting overrides the other:

    If you leave the SSID-level roaming cache settings at their default values but change them for the hive, then the AP applies the hive-level settings.

    If you change the roaming cache settings for an SSID, then the AP applies those settings to clients using that SSID whether or not you change the hive-level settings.
    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    Clearing the cache of the AP still gives us the incorrect VLAN IP address.

    Does that mean it is our DHCP server remembering the MAC address of our computer and re-issuing or not allowing current IP address to be released and therefore not re-assigning the new VLAN IP address?

    Thank you for all your help. It would appear the problem is not related to the AeroHive units. We are now looking into an Network Policy Server. Which is what other schools near us are using.
    Photo of Brian Ambler

    Brian Ambler

    • 245 Posts
    • 126 Reply Likes
    I suppose it is possible that the DHCP server is the issue, though I will admit that I haven't run into such a problem before myself. What platform are you utilizing for your DHCP server (Microsoft, Apple, Linux, etc.)?
    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    We are using Windows 2008 R2 Enterprise and 2012 DataCenter - for DHCP and backup DHCP.

    One of our other staff have just talked to a local school and they said we need to check our VLAN probe and make sure it returns correct values.

    Ours is currently not returning correct values. Looking into iphelper addresses and DHCP options.
    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    We think we have solved the problem. Not sure why this was happening.

    What we worked out was when we first checked the aerohive VLAN probe it was showing the correct information.

    After about 30 minutes the VLAN probe no longer showed the correct information. We had been using superscope DHCP scopes and had all VLAN steering scopes under the superscope. (this did work when first tested). Then we checked again and the VLAN probe was showing incorrect information. We could replicate this by deactivating the scope removing it from the superscope and reactivating. Then we could move it back into the superscope and it would continue to work, but only for about 30 minutes.

    So we have kept the scopes outside the superscope and all is working well.

    Do you know if AeroHive has any problems with superscopes? Or can you suggest any options in the superscope that could be causing this issue?
    Photo of Mike Kouri

    Mike Kouri, Official Rep

    • 1030 Posts
    • 271 Reply Likes
    Michael,
    This is only my opinion, not the official Aerohive stance: superscopes are a hack created by an organization that couldn't figure out how to advise people to use multiple scopes and relay agents. This blog (http://robertparten.com/dhcp-multiple...) says it better than I could.
    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    Things are working, almost. There are just the intermittent logon errors as shown below, but most of the time everything is working, even though we are seeing incorrect information on the active clients page.

    I'm not sure if this is as expected but I feel this should not quite happen the way that I am seeing it.

    While watching the active clients page of hive manager, we notice the following behaviour.

    We have found there is a difference between the active clients page automatically refreshing (set to 5 seconds) and the click the tick box and select "refresh client", from the Operation box drop down. The auto refresh seems to take a few minutes to update the information about the clients. By selecting the client and clicking the refresh client the information is updated instantly.

    Each of the following is after a manual "refresh client" has been performed.

    When a laptop boots up to the logon screen, we can see that the computer logs on and gets an IP address in VLAN 16, shows VLAN 16 and it has the correct computer User Profile Attribute (UPA) and shows the username as expected as host/%computername%.FQDN.

    When a Staff user logs on we can see a VLAN 20 IP address, VLAN 20 and UPA correct for staff, username shows the logged in username.

    When this user logs out back to the logon screen we see some weird things.
    We still have the VLAN 20 IP address, VLAN 20 and staff UPA and showing username as host/%computername%.FQDN.
    I would expect to see the IP address change back to VLAN 16, show VLAN 16 and have the computer UPA.

    If a student now tries to log on for the first time to this computer we intermittently get an error saying "there are currently no logon servers available to service the logon request" and the user can not log on. After clicking OK, the active clients page now shows the correct computer authenticated information. If the student tries to login again straight away the student can log on and we see the correct information for a student. VLAN 16 IP address, VLAN 16 and student UPA, and username showing the logged on student's username.

    When a student logs off back to the logon screen, we see the student UPA stay. All other settings show as expected, VLAN 16 IP address, VLAN 16, username shows as host/%computername%.FQDN. This is where I would also expect to see the computer UPA show automatically. I think technically the IP address is actually held as a student IP at this point, it is just the same IP address as a computer authenticated IP address.

    Another thing we have tried is to move the computer authentication to VLAN 2, but all the same mismatching and behaviour occur, and yes when the student logs out we see student IP address and VLAN attributes are kept.

    Is this behaviour as expected?
    Photo of Andrew MacTaggart

    Andrew MacTaggart, Champ

    • 483 Posts
    • 86 Reply Likes
    Do you have the CoA checked ?

    http://tools.ietf.org/html/rfc3576

    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    Yes CoA is checked
    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    Further testing has shown that the certificate that we have to manually push to our college owned Win7 devices gets pushed to iOS, Android and MAC OSX devices automatically.

    Is there any way other than importing 800+ MAC addresses to allow only college owned devices to be able to connect to this SSID? Can we stop aerohive from sending the certificate?

    We have also set up a BYOD CWP with PPSK to authenticate from AD, so that staff/students can bring their own device, and also want to do VLAN steering on this SSID but the options are not available when PPSK is selected.
    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    We have configured computer authentication only on the 802.1x SSID. All our domain computers are authenticated using the certificates and client monitor showing SSL, PEAP, etc.

    All non domain computers (Win 7,Win 8) are rejected because they do not have the certificate. All iPad's and Android's are rejected because they try to use user authentication and we have not configured user authentication.

    We also have MAC OS X laptops that need to be configured for computer authentication.

    I have configured an 802.1x System Profile and imported the certificate into system keychain using Keychain Access. When I attempt to associate the certificate to the system profile I get an error saying

    "No certificates found" "Certificate authentication cannot be used because your keychain does not contain any suitable certificates. Use Keychain Access to import the appropriate certificates into your keychain. If you do not have the certificates required for authentication contact your network administrator"

    When I try to activate TLS I get the following error.

    "Turning on TLS will cause authentication to fail" "TLS can't be enabled because your keychain does not contain any suitable certificates. Use Keychain Access to import the appropriate certificates into your keychain. If you do not have the certificates required for authentication contact your network administrator"

    When I connect to the computer authentication only SSID the MAC pops open a username and password box. When I type in my credentials I do not get an IP address from DHCP (I get a 169.254.x.x) but the 802.1x is showing connected for about 1 minute and then shows authenticating, and does not change.

    I am using the default AeroHive Default_CA certificate.

    I have tested the MAC on a SSID that still has computer and user authentication. It pops open a username and password box and will authenticate as a user authentication using SSL and PEAP when the certificate is in the keychain. When I remove the certificate it will ask to accept the certificate and place it back into the user keychain, and authenticate as expected.

    Is there something else I need to do to the certificate for this?
    Photo of Andrew MacTaggart

    Andrew MacTaggart, Champ

    • 483 Posts
    • 86 Reply Likes
    EAP-TLS not an easy task, I am currently only using PEAP.

    I'll try to setup up EAP-TLS for testing here and see if I can get it working.
    What os X are you running

    EAP-TLS requires machine certs[identity certs] and server cert. Also if you are using the HIVE as CA you would want to import the CA cert [public key] as well. The CA should sign the Machine cert and the Server cert.

    import to the system, also I find that after import you have to click on cert and manually say always trust this cert

    when you create profile with apple configurator and select TLS, it asks you for the Identity Cerificate, this should be available after you add the identity cert to the cert payload.
    the identity cert will need the private key and public key both signed by the CA as well. The HIVE can create both in one.

    Maybe these will help

    http://www.afp548.com/2012/11/20/802-...

    http://www.apple.com/education/resour...

    http://training.apple.com/pdf/WP_8021...
    Photo of Andrew MacTaggart

    Andrew MacTaggart, Champ

    • 483 Posts
    • 86 Reply Likes
    I created an Identity Cert for Mac os X 10.8, selected the option to place the private and public together

    Exported the .pem
    renamed the .pem to .p12
    imported .p12 to the credential tab of the profile
    selected tls for accepted tls
    then I was able to select the Identity Certificate

    So I think you can place all the certs needed in the profile.
    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    I'm on 10.6.8.

    When I rename to .p12 I can not import the certificate, (greyed out unable to select). If I rename it to .cer I can import but it is not accepted by TLS.

    Maybe I'm doing something wrong.

    Can you step me through the creation of the identity cert in HIVE?

    I go to Advanced Config -> Keys and Certs -> Server CSR -> fill in details and create
    Sign by Hivemanager and combine certs
    Photo of Andrew MacTaggart

    Andrew MacTaggart, Champ

    • 483 Posts
    • 86 Reply Likes
    Hi Michael

    10.6.8 is a cat of a different color.

    Assume you have created CA in Hive, should have private key and public key, radius server should have the CA public key so it can verify ca signed certs

    Radius will also have a Cert it uses for the eap process, signed by the hive CA

    Go to configuration advanced keys and certificates
    create a machine csr and sign it with the hive CA

    fill in the machine info



    Sign it and combine it



    move to the manage certs



    select it



    export it



    for 10.6 you may have to rename it .cer or .der if p12 is greyed out.

    maybe you can gleam some insight from this

    https://jamfnation.jamfsoftware.com/d...
    Photo of Michael Drummond

    Michael Drummond

    • 36 Posts
    • 0 Reply Likes
    Hi Andrew,

    I've just come back from a few of days away. Still trying to get our college owned MACs to use a computer authentication to steer them down a separate VLAN to the domain Windows PC's.

    I have configured a default VLAN that goes no-where, and then based on only computer authentication I have college owned windows staff laptops going to one VLAN and college owned windows student laptops going to another, using two memberof groups in active directory each group with a list of machine names. If the staff bring their own device, they are moved into a basic VLAN based on their username and students BYOD to another. All from 1 SSID.

    Unfortunately I can not get a college owned MAC to use computer only authentication. It always asks for a username and password.

    TLS authentication is appearing very difficult. I guess it does not need TLS but that appears to be the only way I can achieve a computer authentication for a MAC. You said you are using PEAP. Is that just user PEAP authentication or machine PEAP authentication?