Radius session not found error on Guest Portal

[Arne Bier]

Hi

I have seen this a few times in ISE 2.2 and 2.3 in my Guest Portal - does anyone know what could be causing this?

My customer is seeing it more often than I have (in the lab) and in my experience I thought it had something to do with the amount of time I wait before I enter my credentials into the page and hit Logon button (I suspected at the time that I had the page up for 10 minutes and that the web server timed out).  If that is the case, is there a limit to how long the web server keeps that login session alive?

[Craig Hyps]

Make sure running current patches.  This message is typically due to user not logging in before RADIUS session timed out. This timeout value will either be controller default or value returned via RADIUS.  In either case, the redirect is pointing to a specific PSN with a specific Session ID listed in the URL.  If there is a refresh for same page, it will again attempt auth with same PSN and Session ID.  If session already terminated, you would get this error.

We implemented a feature in ISE so that browser will provide a local timeout and force you to click a button that sends a request to a retry URL, (1.1.1.1, by default).  If properly redirected, then this will force the page to be redirected to fresh redirect URL containing current PSN and Session ID.

/Craig

[Arne Bier]

thanks Craig.

I don't quite follow the last paragraph about the 1.1.1.1 - can you please expand on that ?

How does the browser force you to click a button?

What is meant by "if properly redirected"?  What do I need to look for (or do) here?

As far as I can tell, once the user sees this on their browser, the page persists - there is no 'auto recovery'.  They often re-associate to the SSID before they can login again.

We have Cisco WLC session timeout set to 900 sec (15min).  This is the unauthentcated timeout value while user is redirected to portal.

Customer comments today:" The user entered their details immediately when prompted,  I watched her  enter her details when prompted and [error] was immediately after being prompted.  I have also seen this error prior to this and in this case there was no delay in the user entering their details also.  On the other occasion I had a contractor trying to connect I was with him while trying to connect, I had created his account printed out his details handed it to him and watched him enter details.  He also received the error and there was no delay on this occasion either,  in the end we gave up trying to get him connected."

regards

[Craig Hyps]

Separate from RADIUS session timeout, there is also a browser timeout as depicted below (hard-coded for 5 min)...

5 minutes later...

Clicking the Retry button will send request to the Retry URL, NOT the original redirect page.  The Retry URL is configured under Administration > Device Portal Management > Settings > Retry URL.

Checking proper redirection would be validating the policy returned to wireless controller and viewing client session details to verify that 1) Correct Redirect URL applied and 2) Correct Redirect ACL configured on controller and sent in RADIUS to ensure that requests correctly result in getting web portal to correct PSN (the same one servicing RADIUS auth).

If getting a web login page, then very likely redirect is working, but just make sure it is to correct PSN.  Also, make sure that Calling Station ID set to MAC address and not IP address and that CoA properly configured and working.  Look at the URL in the address bar of user's browser.  Does it match the one on ISE?  Disable suppression for the client in ISE and see if another session is getting triggered for same client, thus nullifying the previous session ID for web auth.

Is load balancing in place where requests may be getting sent to different PSNs?  Is this a guest/anchor setup and hitting issue with different sessions IDs from foreign and anchor (disable RADIUS Accounting on anchor).

If still having issues, then please open TAC case to troubleshoot root cause. I would be interested in learning what is discovered if none of the above resolve.

Craig

[Arne Bier]

Good to know about the 5 min hard coded timeout in browser. I have seen the browser timeout with that message.  So my 15min WLC session timeout should be enough to allow them to retry and try again.

The text under the retry URL says "Retry URL for onboarding" which is why I never used it - I don't do BYO.  In a simple Guest Portal case, what URL would I even put in here?  I want the user to retry on the same Guest Portal and was hoping that the ISE-generated redirection URL would still be valid for that user who performs a browser retry.

Calling-Station-Id is MAC and always has been.

I cannot see the PSN name in the client browser because we use the option 'Static IP/Host name/FQDN'  in the Authorization Profile.

F5 load balancing is indeed taking place and I will look into this with more detail.  Our persistence logic may have a flaw.

There is no guest anchor - it's just one WLC talking to an F5 VIP, which has two PSN's as pool members.

This is tricky to troubleshoot because it happens sporadically and I cannot reproduce this in my lab.  If I could reproduce this easily then I'd have something to go on.

thanks for all your advice and suggestions.  I will post here if I make any progress in solving the case

[Craig Hyps · Accepted solution]

The Retry URL is not intended to be the actual page, but any target that is routeable and will be captured by redirection.

"I cannot see the PSN name in the client browser because we use the option 'Static IP/Host name/FQDN'  in the Authorization Profile. "

Congratulations.  ISE is working as expected, but the LB is not.  I am pretty certain this is your issue.  This type of config requires that F5 is able to bind the L3 request based on client IP or session ID to the same RADIUS session.  Here is one example: F5 LTM loadbalancing Radius and HTTP traffic for ISE - Cisco

Based on the LB algorithm, there may be a 1 in X chance that the LTM happens to redirect the web request to the correct PSN, so may not see 100%, but if more than 2 PSNs, expect you will see it more than half the time.   And once persisted to a given PSN, any retry will end up in same connection.

Regards,

Craig

[Arne Bier]

Hi Craig

the jury is still out on that one ... we have implemented persistence logic on the F5 based on the Cisco/F5 document and it's been working well to my knowledge.  Persistence is based on Framed-IP-Address.

I can't reproduce the issue and we're waiting for more feedback from the customer.

Here's the thing that concerns me - why is the error displayed only AFTER the user enters his credentials?  Surely if the client PC lands on the wrong PSN, then that PSN's web server should complain immediately about it, and not wait until the user types in his credentials.

This made me think that perhaps the Sponsor portal was not replicating the guest accounts to all PSN's in time.  But so far my testing has not proven that theory either. Then again, if replication were an issue, then the error message would be the standard 'Authentication failed'.

[Craig Hyps]

Do endpoint debug (option from Live Log - Right-click MAC address) and verify which PSN it hits.  Check persistence and validate that RADIUS Server and Web Server are one in same.  Packet capture from server side of F5 could also help verify.

With redirect on static hostname, sticky MUST be configured to track web traffic attribute to RADIUS persistence table.  Otherwise, it will not find the session ID.  If hitting the same PSN, then need to verify the translations occurring at LTM to ensure that what is sent and returned by it is something that PSN will accept.

For one client, do it as called out in guide where it is allowed to pass and validates it works.

I trust that you have since opened a TAC case to help troubleshoot?

[sanket]

Check your Authorisation policy- (eg- authrpolicy1): Goto to Policy->results->Authorisation profile->authrpolicy1->common task-> set the Reauthentication time to 3600 sec.