07-15-2016 02:27 PM - edited 03-10-2019 11:56 PM
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,
12-17-2018 03:56 PM - edited 12-17-2018 03:58 PM
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:
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
01-07-2019 03:26 PM
Any ideas on what other levers I should pull to continue troubleshooting?
Thanks again for all the help!
01-08-2019 07:38 AM
04-09-2019 01:03 PM
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
04-10-2019 08:50 AM
04-10-2019 12:34 PM
06-14-2019 03:56 AM
I have the same issue. Key chain is properly implemented into ISE.
Any ideas?
06-19-2020 03:22 PM - edited 06-19-2020 03:27 PM
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
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: