VLAN assignment fails for mobile devices "waking up"

Talkabout
Talkabout Posts: 34  Freshman Member
First Comment Friend Collector
edited May 21 in Wireless

Hi all,

recently I realized that some mobile devices (phones and tablets) have an IP in the wrong IP range. We have here several VLANs active and those devices are correctly assigned to the VLAN 30 when they initially connect to the AP. But at some point (I did not figure out exactly when this happens) the devices receive an IP from VLAN 1 (which is the default VLAN configured for the SSID). When reconnecting the device to the AP it immediately receives VLAN 30 again. I have checked my RADIUS configuration and all other places where I suspected an issue, but was not able to find the cause. Is it possible that when a device "wakes up" from sleep and reconnects to the AP (or resumes an existing connection) the RADIUS authentication, which assignes the correct VLAN) is not executed again and thus the AP considers the default VLAN? Is this something that can be fixed by using the reauthentication timer (which is 0 in my case)? Any other hint what is going wrong? We have 2 APs running here, can this be an issue with roaming?

Thanks!

Bye

«13

All Replies

  • Talkabout
    Talkabout Posts: 34  Freshman Member
    First Comment Friend Collector
    edited November 2019

    Hi all,

    I can confirm that changing the standard VLAN id for the SSID makes the devices getting an IP address in the corresponding range, so this setting is directly related. Still I am not able to reproduce the behavior consistently, only after waiting a few hours without touching the mobile device and then waking it up the issue is visible (sometimes). Very confusing...anybody has an idea?

    Thanks!

    Bye

  • Zyxel_KathyLin
    Zyxel_KathyLin Posts: 58  Zyxel Employee
    First Answer First Comment Friend Collector

    @Talkabout

    The mobile phones only have a connection behavior. What IP to take is mainly determined by the SSID VLAN and the overall network settings.

    I think you can try

    1. confirm the same SSID is set to the same VLAN.

    2. Reset the phone network setting.  

  • Talkabout
    Talkabout Posts: 34  Freshman Member
    First Comment Friend Collector

    Hi @Zyxel_KathyLin ,

    currently it seems that the problematic behavior is somehow related to changes done to the WIFI settings on the ap during existing connections of clients. I am still validating this, but here is what I think happens:

    1. clients connect to ap
    2. clients execute radius authentication process and receive vlan to connect to
    3. clients receive ip address via dhcp (depending on vlan the dhcp server is different)
    4. wifi setting is changed on the ap web configuration page (and thus internally the ap restarts wifi)
    5. the client wifi connection is not resetted, but the ap's information about the vlan for the client seems to be lost.
    6. after the clients dhcp lease expires and the client asks for a new ip, it receives an ip in the default vlan (configured in the ssid settings) instead of the one received from radius server

    What I do not get here is why the ap loses the information about client vlan but does not reset the connection so the client has to authenticate via radius again?

    Still under analysis on my end, will revert back.

    Thanks!

    Bye

  • Talkabout
    Talkabout Posts: 34  Freshman Member
    First Comment Friend Collector

    Hi all,

    unfortunately the issue occured again... I am not able to figure out the cause of it... I added a trace into my Radius implementation and there is no entry when the guest vlan is assigned. Somehow the client receives a new ip WITHOUT being authorized by RADIUS, how can this work? Also the AP log (debug) does not provide any information... Is it possible to have more detailed logging about the actions taken when clients are connected to the AP? It would be great if a technical expert could take a look at that issue as it seems there is a bug in the firmware...

    Thanks!

    Bye

  • Talkabout
    Talkabout Posts: 34  Freshman Member
    First Comment Friend Collector

    Hi all,

    today again, various devices have been assigned an IP from the guest net although the RADIUS authentication provided a different one. Is there really nobody who could help here...???

    Bye

  • Talkabout
    Talkabout Posts: 34  Freshman Member
    First Comment Friend Collector

    HI all,

    today I did some more testing and am now able to reproduce the issue.

    ap1 => 1st floor, default vlan = 100

    ap2 => 2nd floor, default vlan = 100

    VLAN1 => private Wifi

    VLAN100 => guest Wifi

    • Mobile device logs into ap1 with LDAP credentials via RADIUS => receives vlan 1 via radius response and an ip address in the correct subnet
    • Mobile device moves to 2nd floor and roams to ap2 => device remains in vlan 1 and keeps the correct ip, everything works as expected
    • Mobile device moves to 1st floor again and roams to ap1 => device connects and suddenly receives an IP from guest subnet, which is vlan 100

    Here it doesn't matter if device connects first to ap1 or ap2, but the second time the device tries to roam to an ap it is not associated with the correct vlan any more. As already mentioned above on radius side (via logging) I can see, that in all cases the correct vlan 1 is returned back for any authentication request, still the device receives a wrong one.

    For me it seems to be a bug in the vlan treatment of the ap, or is there any setting I can try to avoid the problem? It is getting really annoying as devices are suddenly blocked access to internal resources because they move to the guest vlan... Please fix it or tell me how to avoid it!

    Thanks!

    Bye

  • GreenPuzzle
    GreenPuzzle Posts: 30  Freshman Member
    Zyxel Certified Network Administrator - WLAN First Comment First Answer Friend Collector

    Base on your statement, is this a dynamic VLAN application with RADIUS attribute settings? While internal user should get IP address in VLAN1, and other guest stations get IP address in SSID VLAN.

    Since the behavior can be reproduced in roaming case, I want to clarify some settings and try to reproduced it in my own site:

    1. is there a NXC engaged in the authentication process, or AP directly access RADIUS Server for user authentication?
    2. Is 802.11r enabled or not?

    Before reproduce and further analyze, below are some points I think you can check:

    1. Base on your statement, RADIUS server reply to the auth-request with correct VLAN settings, while AP sometimes still assign wrong VLAN to client. Could you please check the access-accpet packet on AP-receiving side?(compare both normal & issuing case) If settings are correct, the AVP"Tunnel-Private-Group=Id" should include the internal VLAN.


    image.png


    It will be nice if you can directly Private Message/Attach the AP's start-up configuration file.


    Best Regards,

  • Talkabout
    Talkabout Posts: 34  Freshman Member
    First Comment Friend Collector

    Hi @RichardHan ,

    I am so happy that finally somebody is taking care... thanks a lot!

    here are the answers to your questions:

    1. I am not using any controller, the APs are directly accessing the RADIUS server
    2. I am not sure how to enable 802.11r. The only thing I have found is "802.11r assissted roaming" which is in beta state. I have tried with and without this setting, no change.


    1. I do not know where exactly I can find the RADIUS communication log on the AP, can you please give me a hint?

    I have attached the startup config file (removed passwords and IPs).

    startup-config.zip

    Thanks again for your help, it is much appreciated!

    Bye

  • GreenPuzzle
    GreenPuzzle Posts: 30  Freshman Member
    Zyxel Certified Network Administrator - WLAN First Comment First Answer Friend Collector

    @Talkabout

    Hi, you can capture above packets on the path between AP and RADIUS Server.

    The story is, when wireless station execute 802.1X authentication, AP must negotiate with RADIUS Server to verify user's credential. After station passes the authentication on RADIUS server, then RADIUS server then sends an "access-accept" to wireless station to prove the authentication success. Where the VLAN attribute you've set on RADIUS server for Internal user will be included in AVP column.

    You can mirror the port on access switch where AP directly connected to. Ask switch to send a copy packet to your monitor laptop, then you can examine the content to see if the VLAN attribute is set correctly.

    BTW, is this issue occurs on specific devices (Samsung/iPhone, with specific firmware version)? Or all wireless stations will occasionally suffer for this issue?

    One concept is, each station has its native roaming mechanism, but they must reauthentication when roaming to another AP. So it's strange that the issue only happens on 2nd time roaming. (Especially the station pass the authentication on RADIUS.)

    Still working on the issue reproducing, let's keep in touch, looking forward to your update of RADIUS packet :)

  • Talkabout
    Talkabout Posts: 34  Freshman Member
    First Comment Friend Collector
    edited December 2019

    Hi @RichardHan ,

    I have now captured the RADIUS packets. I have done the following steps to reproduce the issue:

    • disable WIFI on mobile (Android)
    • activate WIFI on mobile at 1st floor. RADIUS response:

    Sent Access-Accept Id 162 from 192.168.XX.XX:1812 to 192.168.XX.4:53042 length 0

    Thu Dec 12 17:39:06 2019 : Debug: (11)  Tunnel-Type := VLAN

    Thu Dec 12 17:39:06 2019 : Debug: (11)  Tunnel-Medium-Type := IEEE-802

    Thu Dec 12 17:39:06 2019 : Debug: (11)  Tunnel-Private-Group-Id := "1"

    Thu Dec 12 17:39:06 2019 : Debug: (11)  MS-MPPE-Recv-Key = XXX

    Thu Dec 12 17:39:06 2019 : Debug: (11)  MS-MPPE-Send-Key = XXX

    Thu Dec 12 17:39:06 2019 : Debug: (11)  EAP-Message = XXX

    Thu Dec 12 17:39:06 2019 : Debug: (11)  Message-Authenticator = XXX

    Thu Dec 12 17:39:06 2019 : Debug: (11)  User-Name = "user"

    Thu Dec 12 17:39:06 2019 : Debug: (11)  Proxy-State = 0x35

    Thu Dec 12 17:39:06 2019 : Debug: (11)  Tunnel-Type += VLAN

    Thu Dec 12 17:39:06 2019 : Debug: (11)  Tunnel-Medium-Type += IEEE-802

    Thu Dec 12 17:39:06 2019 : Debug: (11)  Tunnel-Private-Group-Id += "1"

    • go to 2nd floor, mobile roaming to ap2. RADIUS response:

    Sent Access-Accept Id 120 from 192.168.XX.XX:1812 to 192.168.XX.6:44798 length 0

    Thu Dec 12 17:39:27 2019 : Debug: (22)  Tunnel-Type := VLAN

    Thu Dec 12 17:39:27 2019 : Debug: (22)  Tunnel-Medium-Type := IEEE-802

    Thu Dec 12 17:39:27 2019 : Debug: (22)  Tunnel-Private-Group-Id := "1"

    Thu Dec 12 17:39:27 2019 : Debug: (22)  MS-MPPE-Recv-Key = XXX

    Thu Dec 12 17:39:27 2019 : Debug: (22)  MS-MPPE-Send-Key = XXX

    Thu Dec 12 17:39:27 2019 : Debug: (22)  EAP-Message = XXX

    Thu Dec 12 17:39:27 2019 : Debug: (22)  Message-Authenticator = XXX

    Thu Dec 12 17:39:27 2019 : Debug: (22)  User-Name = "user"

    Thu Dec 12 17:39:27 2019 : Debug: (22)  Proxy-State = 0x31

    Thu Dec 12 17:39:27 2019 : Debug: (22)  Tunnel-Type += VLAN

    Thu Dec 12 17:39:27 2019 : Debug: (22)  Tunnel-Medium-Type += IEEE-802

    Thu Dec 12 17:39:27 2019 : Debug: (22)  Tunnel-Private-Group-Id += "1"

    • go to 1st floor, mobile roaming to ap1. NO RADIUS log. Device gets wrong VLAN assigned (receives an IP from guest net).

    This means that when roaming back to ap1 this ap does not execute the authentication to RADIUS any more. It seems it somehow caches the state of the client but without the proper VLAN id. Does that make sense to you?

    By the way, the problem occurs with Android, iOS and Windows 10 devices, so it is not specific to a particular OS.

    Thanks again!

    Bye

Categories

Wireless Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）