How to tweak Web-Auth Policy timeout on WLC?

[Dmitry Kalyuzhny]

Hello,

Is it possible to change Web-Auth Policy timeout? Currently I am talking about 5508, but it could be WiSM also.

Thank you.

[Scott Fella]

If you go to the WLAN SSID advanced tab, the session timeout is what you need to define. Or example, 28800 seconds would be 8 hours. So guest users would have to log back in or accept the Webauth after the time set.

Sent from Cisco Technical Support iPhone App

[weterry]

The Webauth policy timeout (as in, how long we wait for a user to get out of WEBAUTH_REQD) is like 5 minutes, and AFAIK there is no way to modify it.

Generally speaking, there is no reason too either. After all, if they aren't web authenticating, then what are they doing?

With that said, use case would be if you had a PREAUTH ACL and you wanted users to browse a subset of addresses without having to webauth. 

A semi-supported workaround would be for you to enable IPv6 on the wlan. With IPv6 enabled, the webauth policy timer is disabled (story for another day).  However, I must stress, whenever more ipv6 features are added to the WLC (like making it native IPv6), eventually it might come to a point where enabling ipv6 does NOT disable webauth....  Whether thats 1 year or 3, I have no clue....  So use that as a workaround and perhaps push for a better long term solution (whatever the reason may be)

[Dmitry Kalyuzhny]

Thank you.

"With that said, use case would be if you had a PREAUTH ACL and you wanted users to browse a subset of addresses without having to webauth."

This is exactly our case. We are trying to create a sort of 'walled garden'. It should be a long term solution, so we will rather go different way than implement this kind of workaround. If Cisco does not decide to add a new feature to control the timer into the new version of the controller software :-)

Thanks again.

[weterry]

This "workaround" might be viable for 5 more years for all I know.... I just wanted to mention it to be clear that it is just a side-effect kind of "workaround".

My suggestion would be to contact account team and drive a feature for this, it may very well be on the radar. They would be better at giving a timeline or other potential ideas/features (perhaps anything coming down the pipe).

[r-tyrell]

Hello, and thanks for tip on how to tweak the Web-Auth Policy timeout.  Can you tell me what version of code you were running when enabling IPv6 on the WLAN?  I'm currently running 7.0.116.0 and when I attempt to enable IPv6 I receive the error message "Cannot enable IPv6-bridging when DHCP Address Assignment is enabled for WLAN".

Thanks!

[weterry]

So you have the DHCP required box check on your wlan?

The way I see it, the box tells the WLC that it is not allowed to pass any traffic from the client (RUN state) except for DHCP, and then after we learn IP from DHCP then we are good to go.. The IPV6 box however puts a client in a RUN state even without a dhcp address (so that ipv6 can flow through).

I suppose that means the two options are mutually exclusive and it is a good thing there is a box that tells you that you can't do it

[r-tyrell]

I actually don't have the DHCP required option checked on the WLAN.  I am using the internal DHCP Server on the Controller.  This is a WiSM and not a 5508 Controller.

I have decided to open another TAC Case on the issue.  There should be a way to adjust the Web-Auth Policy to something other than 5 minutes.  The main reason being of when certain devices are put into "sleep" mode and disassociate from the WLAN.  When they wake back up, they are required to click on the "I Accept" button on a splash page etc.

Thanks again-

[weterry]

You need to be clear on what thing though, the webauth policy timeout has nothing to do with authenticated users.

This is time we will wait on a client to perform a Webauthentication and move to a RUN state.

If a user is hitting webauth timeout, they are going to be removed because they aren't a working client anyhow.

The only exception to this pre-auth ACL I suppose where you want users do webauthenticate if they go outside of a specific webpage, but have unlimited access to that one page.

Either way, I agree the timer needs to modifiable, but you need to make sure you're fighting for the right timer.

If your clients are going to sleep and they Dissasocciate, of course they will have to reauth, the disassociate removed them from the enterprise network entirely.

If they are sleeping though, and timing out because of a normal IDLE timeout (not web policy timeout), that is modifed on the Controller TAB of the GUI for "User Idle Timeout".

[r-tyrell]

After working with TAC and per your message, it does look like the problem has to do with having to re-associate.  I was confused as to the direct cause of the problem due to a number of WEB-Auth Policy timeout messages received during debugs etc.

Thanks again for the information.