-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? ' When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '
-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? ' When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '
-- Each morning when I wake up and look into the mirror I always say ' Why am I so brilliant ? ' When the mirror will then always repond to me with ' The only thing that exceeds your brilliance is your beauty! '
Do you have specific set of clients impacted? (only impacting apple devices etc.)
If you are using 9800, For HTTPS redirection you can enable Web Auth intercept HTTPS under the web auth parameter map, but there will be a hit on CPU usage of WLC. If you need more support please post the web auth parameter map configuration, redirection ACL and http/s server status along with the controller model, code and CWA or LWA
I am using 5508 WLC .secure web enabled .HTPS enabled .but not getting gui of WLC in https also web auth page not coming automatically .virtual ip is 2.2.2.2.If i enter ip http://2.2.2.2 in chrome browser than the page is comming.,
@vikas01234das opening the page directly with http is *not* the same as a redirect to https! If you enter any https domain which then gets redirected to your https page then the browser/device expects to see a certificate matching the domain entered initially. If it doesn't then the page is blocked. Some browsers will still provide a warning and option to proceed. Most captive portal assistants will simply block the page. Similarly even when the redirect is from a http page (that's what all captive portal assistants use now) the https cert *must* match the domain of the page and be issued by a trusted root CA. This is the reality you must work with or you WILL have problems. Security enforcement is getting stricter all the time on devices and browsers so something that worked 10 years ago will not work today.
Is there any more in depth info about this? I'm trying to find more information which explains the interaction of said devices but can't find anything concrete
The WLC simply intercepts the TCP connection and responds masquerading as the destination IP address. Because most browsers and clients now strictly enforce security with certificate verification https will normally be blocked and is NOT recommended. All device and browser captive portal detection now use http (not https) because that can be safely redirected.
The other reason you should not redirect https is because on modern devices you have dozens of apps trying to connect on https. The connections will all fail (because the redirect to captive portal fails certificate verification) so all you do is overload the WLC. 8540 running 8.10 code can cope with a moderate number of these - older WLC and code cannot. 9800 running IOS-XE is very weak at handling https redirects and will simply cause high CPU and dropped customer connections.
The captive portal URL you redirect to should be https (with valid trusted public certificate which matches the fully qualified domain name of the portal) but you should only intercept and redirect http traffic from the client eg http://www.neverssl.com or any of the OS and browser URLs as per https://en.wikipedia.org/wiki/Captive_portal which as you can see are always http because they're intended to be redirected.
