This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
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.
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.
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?
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,
Has there been a remedy to your issue, we are seeing this issue also. Very odd that the page doesn't work with Chrome, but is receiving the proceed link in Mozilla Firefox and Safari.
The TAC wants me to do this.
The solution is adding your ISE self-signed certificate to the trusted zone of your browser. Unfortunately, it is Google Chrome’s security feature.
i have done this and still its not working. This is the default self-signed server certificate in system certificates under certificates in ISE right? IE works fine but chrome and mozilla are not redirecting
So in a large deployment...i guess if adding the self-signed is a solution, then this cert will have to be pushed to all the clients...Or how to go about it?
Ok, but are you sure thats the cert that ise is actually sending to the browser? Also, if the cert is sha1, chrome will still not like it.
I have this same issue, even before the user gets past the web redirect acl, the controller is proxying connections to connectivitycheck.gstatic.com and replying to the client /generate_204 which tells the client its not behind a captive portal...so the device doesnt listen to the redirect.
*webauthRedirect: Dec 14 16:42:32.142: 40:4e:36:23:85:c5- parser host is connectivitycheck.gstatic.com
*webauthRedirect: Dec 14 16:42:32.142: 40:4e:36:23:85:c5- parser path is /generate_204
Has anyone resolved this issue yet?
No unfortunately this didnt work, see the attached logs, no matter what I do, androids are bypassing the web auth acl and thinking they are online?? (the below acl also allowed dns...that was removed for testing...that isnt the issue)
...the more urls we see, we try and block...but we cant seem to block *.google.com/gen_204
Source Destination Source Port Dest Port
Index Dir IP Address/Netmask IP Address/Netmask Prot Range Range DSCP Action Counter
------ --- ------------------------------- ------------------------------- ---- ----------- ----------- ----- ------- -----------
1 Any 0.0.0.0/0.0.0.0 (ip removed for security)/255.255.255.255 Any 0-65535 0-65535 Any Permit 22
2 Any (ip removed for security)/255.255.255.255 0.0.0.0/0.0.0.0 Any 0-65535 0-65535 Any Permit 18
DenyCounter : 469
URLs configured in this ACL