Extending ISE Hotspot Portal timeout

[t-roy]

We haven't been able to find where the timeout setting is for the Hotspot Portals.  We have instances where previously associated clients return to a building after the endpoint has been purged from ISE, the WIFI session helper from the client OS automatically launches the captive portal on their behalf, but by the time they get around to the notification the captive portal page has timed out, so they get a 400 response from ISE.  When this occurs, the client is in CENTRAL_WEB_AUTH state on the WLC, and has an ACL that only allows them DHCP, DNS, and access to the portal.  The client will stay in the CENTRAL_WEB_AUTH state until the radius access-accept from ISE, but since the portal page has timed out, the clients have to forget the WIFI network and start the flow again.  This works, but isn't the best customer experience.

So IF we can extend the portal timeout, how is that done, and what are the ramifications.  If someone sends a DOS attack that takes down a portal, just as an example, could the portal service impact other functions, such as RADIUS/TACACS authentication?

[Arne Bier · Accepted solution]

Hi @t-roy 

There is a 5 minute timeout in the portal page which will cause the page to display that error if the user has not logged in within 5 minutes.

There's an old thread about this.

Perhaps you can hack some JavaScript/JQuery into your portal page to overcome this - but I think it's also tied to the PSN's Session ID logic, since each MAB request creates a unique Session ID in the PSN - the PSN doesn't want to hang on to a SessionID indefinitely - so it makes a hard cut off of 5 minutes.

Do you return a short Session-Timeout on the initial MAB request (e.g. 300 seconds) ? I think that would be useful too, since it would clean up any stale sessions on the WLC if the user has not clicked anything within 5 minutes.

Then, in ISE, return a longer session timeout for authenticated guests, depending on expected usage and DHCP capacity etc. - I also tend to make the DHCP lease times quite short, based on some thumb suck of usage vs. scope size.

[t-roy]

setting the RADIUS Session-Timeout attribute on the 2 policy results is EXACTLY what I needed (in addition to enabling session timeout on the WLC).  My testing so far has resulted in mobile clients either relaunching the portal, or disconnecting from the WLAN altogether, which should eliminate the 400 responses clients are receiving from ISE.  Windows clients see the "click here to try again" ISE message.  Thanks Arne!