cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2562
Views
7
Helpful
6
Replies

global timeout with CWA on Cisco ISE?

dmadland@cisco.com
Cisco Employee
Cisco Employee

Is there a global timeout with CWA on Cisco ISE?  Where is this setting?


Hi. Here are some screen shots from when Gay was trying to use GuestP wifi today. Does this look like DHCP lease time out? What about the message about reaching the maximum number of devices?


This happened when I was actively using the network and ipad and it happened in just a few minutes, 10 minutes maybe but definitely fewer than 30.  When I refreshed the page, it said I had access again? 

When I refreshed again, I got an internal error and it seems to have logged me out forcing me to login again. When I logged in again, I got the Maximum Devices reached error. 

Then it bumped me off the network and put me back on HC_Guest.

1 Accepted Solution

Accepted Solutions

Jason Kunst
Cisco Employee
Cisco Employee

Ive talked with a few SME and there is no option that we know of. Might be good to discuss issues with Tac as well as looks like troubleshooting issues mixed in.

View solution in original post

6 Replies 6

Jason Kunst
Cisco Employee
Cisco Employee

Ive talked with a few SME and there is no option that we know of. Might be good to discuss issues with Tac as well as looks like troubleshooting issues mixed in.

The RADIUS session timeout should control portal timeout.  This is configurable in the Authorization Profile where you return the URL Redirect for CWA.  May need to verify that this session timeout is enforced and not overwritten by WLC when session in WebAuth Required state.

The Max Devices reached seams to be erroneous message based on My Devices Portal error, i.e. wrong error code returned for session timeout. Recommend open TAC case if able to recreate.

Craig

Thanks Craig - i just opened a TAC case on it now. 

Drew S

I was engaged on another request with some similar questions, so wanted to update this thread as well.

The first screenshot shown above is due to the hard-coded browser timeout when you are first redirected to page.  This is independent from the RADIUS session timeout.   It's purpose is to trigger a fresh redirect after the login page has been left idle.  Consider the following scenario...

  1. You attempt to access Google.com and are redirected to a PSN on a specific port and *session_id* for web login.  (The session ID tells ISE which RADIUS session to link for the web request.)
  2. You walk away or work on another task without completing login and now the RADIUS session has timed out.  In the process, MAB auth will occur again and redirect session to a new portal URL which will have a different session ID and possibly a different PSN based on load balancing.
  3. After returning to page (which appears as it did in step 1), you attempt to login but it fails with an invalid / missing session context.

The issue issue is that the browser is still pointing to the original redirect URL with the old session ID.  The intent of this 5-minute browser timeout is to force user to click button which will send a web request to the retry URL (default 1.1.1.1).  This will allow redirection to occur again to the updated redirect URL.  (Note that since the stale URL pointed to a PSN, it was being allowed without redirection!)

In the original error above (screenshot #2), the endpoint should not have registered yet so would be good to get update on what TAC determined to be issue with Max Devices being triggered.  Apparently ISE was tracking the first attempt even though never completed.

Regards, Craig

paul
Level 10
Level 10

Not sure if you are hitting the 10 minute timeout state of being in a CWA condition on the WLC.  From my experience and what I have been told, the WLCs only allow you to reside in a redirect condition (Webauth REQ, Posture REQ, etc.) for 10 minutes.  If you don't move out of that condition you will be disconnected.  Your client will reconnect, but that would be a new session number.

I ran into this issue doing posture monitor mode at a customer.  We redirect only port 80 to the gateway to roll out posturing in monitor mode without affecting end-users.  This works great on wired and VPN, but on wireless if the users don't have the posture module they get kicked off every 10 minutes.  For most users this isn't a big deal as their client reconnects under the covers, but for network admins that are SSH'd into devices it is a big deal.

Not sure if you are running into this. My understanding is this 10 minute value is hard-coded on the WLC and can't be changed.

Hi Paul -

Is there any documents that mentions this 10 minute value that is hard-coded? and possibility of a workaround?

Thanks,

Drew S