WLC 5520, WLAN with session timeout

[Clem58]

Hello,

Do we agree the session timeout enabled on a WLAN is a security feature, but should be transparent for users ? I mean it's only re-authenticating in the background and should not disconnect them ?

[Scott Fella]

Depends on whom you are asking.  I have seen security teams want lower session timers because they feel that a compromised device will still be on the network even after the device is banned until the device session expires or has to go through a re-auth.  I don't look at it as a security "thing", because I want users to have a good experience and have to balance timers with many types of devices that can fail to connect depending on the session timer set.  Just my opinion.

[Clem58]

Thanks Scott, actually we are experiencing some disconnections on some sites. Some other sites use same SSID and don't experience any disconnections.
I wanted to be sure this setting is not disconnecting clients after 30min but only doing re-auth in the background.

[Scott Fella]

You have two timers to look at, the idle timer which is default at 300 seconds and the session timer.  I typically leave the idle timer and disable the session timer or set the session timer to 86400.  There was a bug on the 9800's where it was best practice to set the session timer to 86400 than leaving it unchecked.

You might have other issues, like coverage issues that can cause device to loose connection and them roam later in which the device does a full auth.  Gather info on what devices are working and what are not and if there is a specific area where users experience the issue more that other areas.

[Clem58]

Ok thanks Scott, I'm working with a test SSID and they have just been disconnected, I will disable session time out, and let you know if there is any improvement.

[Scott Fella]

Make sure the idle timer is 300 seconds.  The idle timer has to be lower than the session timer or else in the background, both are set as default.

[Clem58]

And User Idle Timeout is set to 1800s.
[cid:image001.png@01D8178E.E987B6D0]

[Scott Fella]

That is fine, but you can drop that to 300s if needed.  Might vary on the controller model and code, but my 9800 is at 300 for idle.

[Clem58]

It seems disabling session timeout has improved significantly the disconnections issues we had.

I wonder if we don't have a bug with this feature and new Dell laptops, I also suspect the "mac randomization" in Windows 10 to work badly with session timeout.

So I will have to disable session timeout globally on the productionn SSID, do you know if it could impact the current clients connected on it, doing that ? Or it will be transparent ?

[JPavonM · Accepted solution]

Which adapter are those Dell laptops using? Which driver version?

I mention this because if they are using Intel AX adapters then there are some news about a defect that has been fixed in the latest Intel drivers 22.110.(and this is also not seen with drivers before 22.40)

As you can see on Intel's community, there are some threads about L3 connectivity issues when roaming, however you can see that the device keeps associated to the AP (L1-L2) (basically this is happening when doing re-auth that the adapter is not receiving an IP address). Intel moderators informed in those threads about a defect seen on Intel's drivers and they have finally fixed it on this release.

HTH
-Jesus
*** Please rate helpful responses ***

[Clem58]

That's really interesting I will check but the last laptop with issue has a WIFI6 adapter for sure.

[Clem58]

So JPavonM, you were spot on, it was this bug on Intel Driver that was impacting our "Radius" SSID.

So here are my conclusions:

• On a normal behavior, session timeout does not disconnect clients when they re-auth, it's transparent.
• Intel AX201 card with bugged driver causes client to disconnect after 30min when session timeout is set to 1800s.
  • If session timeout is set to below 1800s or above 1800s, this bug is not occuring.
• Disabling globally session timeout on our WLCs has solved the disconnection issues.
• We will also update the Wireless cards drivers for all corresponding clients, but it will take time, that's why the decision to disable globally timeout session has been taken, it was the quickest.

Many thanks JPavonM for your help on this !

[Avrabie]

Anybody knows how this mechanism actually works?

I understand what it does or what are its value limitations (depending on the security type), but can't figure out what actually triggers the client to re-auth. I've been monitoring the air for de-auth/disassoc frames but couldn't find any.

So, how does the client know when it's time to re-auth?

Is this value written down in some field of the beacon or probe response? If so, which is it?

Thank you