cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
11240
Views
13
Helpful
15
Replies

Error 400 with Guest Portal Redirection

NETAD
Level 4
Level 4

Hello, I have a 2 node deployment and I'm trying to redirect to a custom URL for the guest portal. I'm doing this by check the check box for static redirection in the authz profile. When that's configured redirection isn't working all the time. Clients are sometimes are getting an error 400 with a message stating that that the radius server terminated the session. How can this be fixed please. I have ISE 2.4 with patch 6 installed. 

15 Replies 15

Brian Hanson
Level 1
Level 1

We've experienced this same issue as well, "[400] Bad Request" on our ISE Guest Web-Auth portal. We had separate Authz rules built in our Policy for each separate PSN, so that kind of ruled that out. I worked with TAC for two months on this. This issue was intermittent, so very difficult to t/s. It came down to re-creating the issue.

The issue/error seemed to come up, prior to Guest users hitting the "Accept" button ("Authenticating") on our Web-Auth page, if they had auto-reconnect enabled for our Guest SSID, and did not accept the AUP, this error would sometimes come up on their browser, seemingly randomly. If they swiped/closed the browser and relaunched the page, the error would go away and then they would get the AUP page in order to Authenticate.

Ultimately, the issue appears when roaming APs, we would see this in ISE EP Debugs: "PortalWebActionException: Session token validation failed.  Token does not match token in the radius session."

Per the TAC Engineer, this is expected behavior, as when roaming APs, ISE gets new SessionID Token from AP, therefore the original URL redirect link is now invalid, causing the [400] Bad Request error.

"As you can see the error is that the token in the radius session is not matching the most probable reason is that roaming is happening on that session, so the tokens are different, which explains why the issue is not happening at all times. As it is an expected behavior there are no actions to take for now."

Hopefully this provides answers to others, but it still does not really resolve anything for us, as if reoccurring user enters our campus, associates to AP, auto-reconnect to Guest WLAN, then roams AP, will likely get the 400 Error. Just makes it an inconvenience to our visitors/guests, if they do not know to simply just re-launch the browser.