Showing results for 
Search instead for 
Did you mean: 

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.


WebAuth redirect does not work WLC/ISE


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: 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 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 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, 



can you tell us what versions do you using on the WLC and on the ISE with Patch?.



Has there been a resolution to this issue?


Did You Find Some Solution


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?

Rising star

Your redirect ACL content would be interesting to see. Regarding Chrome, the gstatic url, is the url that chrome uses to detect if it has internet access, and if it's being blocked somehow, what you should see is the redirect to your portal, but i would suggest you get yourself a trusted public cert instead of some self-signed cert, also certs with SHA1 and not SHA256 algorithm (minimum) , will also have issues and chrome is especially security aware.

We already have a public certificate in place.

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 and replying to the client /generate_204 which tells the client its not behind a captive the device doesnt listen to the redirect.


*webauthRedirect: Dec 14 16:42:32.142: 40:4e:36:23:85:c5- parser host is
*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 *



Source Destination Source Port Dest Port
Index Dir IP Address/Netmask IP Address/Netmask Prot Range Range DSCP Action Counter
------ --- ------------------------------- ------------------------------- ---- ----------- ----------- ----- ------- -----------
1 Any (ip removed for security)/ Any 0-65535 0-65535 Any Permit 22
2 Any (ip removed for security)/ Any 0-65535 0-65535 Any Permit 18

DenyCounter : 469

URLs configured in this ACL

If captive portal bypass is disabled and still unable to get auto browser does the standard browser work going to an http site? Try

Also work through tac
Content for Community-Ad