cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
19542
Views
0
Helpful
22
Replies

WebAuth redirect does not work WLC/ISE

Hello, 

I hope you have seen this behavior, if not, please share your ideas. we have a deployment of one PAN and 6 PSN nodes across multiples regions in the world. 

Background:

Each location has its own WLC 8500 series and we have a ISE 2.0.

Each WLC redirect to endpoint request to the PAN, the PAN acts as the main central radius.

Behavior:

All sites/branches, the URL redirection portal works fine, in other words, when a endpoint user joing the open SSID Guest, it gets the DHCP settings and when they open or go to any web site, it will automatically redirect to SSL certificate warning and click on continue adn then get the Portal Credentials. 

However, on Google Chrome, it does not open, instead, when they type in the address bar any web site, http or https, it will automatically open a new tab saying: gstatic.com/generate_204 and keeps trying until it says a button connect but it does not do anything. 

What could be the culplrit of this crap URL redirection? 

Troubleshooting made: 

We created another WLAN, still the same behavior. 

Under the same SSID, we set it up a local web aut redirection portal, the same behavior.

Please check the attach file and you will see what Im saying.

Updated Chrome and does not work on Windows 7

On Windows 10, sometimes it works and sometimes it does not work.

On Chrome books, one work and the other one does not work the first attempt.

Debug the client mac address for the endpoint that works and for the one that does not work. Checked everything and they have the same thing. TAC says that the endpoint receives the URL but for some reason the Chrome stops the process and start the redirection to the gstatic.com web site.

Did a comparison with firefox and IE and Microsoft EDge and debug and Chrome with the same and other laptops and the same config appeared as per Cisco TAC. 

They could not determine right away if this was a problem with the WLC or the Chrome app. But do I know that it should be compatible with all top browsers like chrome.

Why it does not work on on WLC if the solution and design was to have the same config across all regions. 

Only on on brach does not work. other ones work fine. 

I regirsted one AP on another WLC and it worked fine. 

other region reigisted their AP with own WLC and the first time they got the gstatic.com web site 

Is it the WLC faulty or what?

Pleas help, what else could I try and prove it is the WLC config or damaged, corrupted , it is very weird cause as I mentioned before, it works fine on firefox, IE, Opera, etc, execpt Google Chrome and Chrome OS, but only on this site, but other say they have not experienced this issue.

Thank you for  your help, 

22 Replies 22

I dont think its the captive portal itself thats the issue, android devices seem to be fooling the controller into getting a response from a cisco site that is clearly not in the redirect url, see the below link:

 

https://socifi-doc.atlassian.net/wiki/spaces/SC/pages/94371841/DNS+Workaround+to+keep+Android+Splash+Page+and+the+Captive+Portal+Notification+active

 

The android phone is sending a port 80 request to http://connectivitycheck.gstatic.com through the controller before its authenticated...somehow the controller is allowing that and proxies the request to the site for the client, and the controller returns a \generate204 to the android...which makes the androud believe its not behind a captive portal...the android wont accept the redirect, which is the crux of the issue. 

 

And this network is 100% external so we dont have control over dns servers.

 

Thanks for the help

Any ideas on what other levers I should pull to continue troubleshooting?

 

Thanks again for all the help!

Yes please work through the tac

Did you find any solutions to this problem? I have the same problem and the TAC could not find a solution


@Jason Kunst wrote:
Yes please work through the tac

 

If tac can’t find did they escalate? Seems to be wireless issue as well

Yes it turns out there was a bug on the PSN, the PSN wasn't sending out the entire cert chain, all we had to do was reboot the PSN and it fixed the issue...when it doubt, turn it off and on again :)


I have the same issue. Key chain is properly implemented into ISE.

 

Any ideas?

Hello team.

There is an associated bug (CSCvj04703). How solve it? Add a third party certificate for the Portal in your ISE deployment. This would fix the issue in all the portals and browsers (including minibrowsers) that you use (it doesn't matter if authenticate local or with saml).

And you avoid install the certificate in all endpoints because any tshoot in a medium or large network could be a headache.

I know is too late but I hope helps!

 

BR

Valeria

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: