cisco ise guest portal timeout

[Richard Lucht]

Hello,

I am working on a quest portal to replace the captive portal on our WLAN controllers.  One question that came up is that what can we do about unregistered users who are just walking by and happen to associate with SSID we setup for the guest portal but we want to kick them off after a certain amount of time.  We don't want our DHCP space taken up by those who are registered users.  Should this be part of the redirect authorization policy or on the controller?

[Jason Kunst · Accepted solution]

Can you please explain further what the problem is and how you want to work.

If somebody is automatically connecting to an open network then the only way to stop it is to secure that network, we recommend using WPAPSK to accomplish this.

the wireless controller User idle time out is 180 seconds this means when they leave the network the session will only stay pinned up for a max of three minutes.

if you’re worried about DHCP IP addresses being exhausted and don’t want to lock down the SSID then you can adjust your lease time

[Arne Bier]

This is handled by two things

1. Relatively short DHCP lease times.  Offer short lease times in your DHCP leases to prevent IP address exhaustion.  Anyone who connects to an open SSID will be given an IP address - there is no preventing that.  But you can make those leases 1 hour long and then the client will renew their lease every 30 minutes.  Just as an extreme example.  Passers by would then only "hog" an IP address for max 1 hour.
2. Set your WLC session-timeout on the WLAN config to be short - e.g. 900 seconds.  This is enough time for a user to be redirected and enter his credentials if he is consciously trying to log into your portal.  Then, if the portal auth was successful, then return a custom, longer Session-Timeout from ISE in the Result Profile. e.g. 8 hours or whatever.  Those walk-by users would only live on your WLC session table for max 900 seconds and then disappear.

I have not had much luck with Cisco WLC's and Session-Idle-Timeout - but the Session-Timeout is an absolute value (in seconds) and this works like a charm