WLC redirect traffic with intercept, make problem to https site to accept

[Filip Po]

WLC 2504, AireOS 8.0.152.0

ISE 2.1 with CWA redirect

Client Android Samsung S4 and iOS iPhone 6s

Problem is, that WLC trying to intercept https redirected session with SSL certificate issued to its virtual interface 192.0.2.1.

And nowadays end points do not accept it and deal it as man-in-the-middle-attack.

So when I do ISE BYOD onboarding on android, i have problem to get redirection from https sites, and also have problem to access play.google.com for Cisco Network Setup Assistant download.

NET::ERR_CERT_AUTHORITY_INVALID

How should I command wlc to do not intercept https traffic with its own certification?

thank you for any advice.

[Sandeep Choudhary]

Did you try to enable https redirection ? if not then give a try.

config network web-auth https-redirect enable

Check this:

https://supportforums.cisco.com/t5/wireless-mobility-documents/understanding-https-redirect-over-web-auth/ta-p/3143359

Regards

Dont forget to rate helpful posts

[Filip Po]

Yes, I follow design guide and also this document.

But instead use local web-auth I am using CWA on ISE.

Dual-SSID BYOD.

Web Auth CMCC Support ...................... Disabled
Web Auth Redirect Ports .................... 80
Web Auth Proxy Redirect ................... Disable
Web Auth Captive-Bypass .................. Enable
Web Auth Secure Web ....................... Enable
Web Auth Secure Redirection ............... Enable
Fast SSID Change ........................... Enabled

[Freerk Terpstra]

Due to the impact on performance and the usability issues like you described, it is actually recommended to keep https redirect disabled. You can undo this behavior with the "config network web-auth https-redirect disable" command. It is some time ago that I have worked with ISE's on-boarding procedure and I'm not trying to scare you, but I foresee another issue when you perform this change.

The challenge you might run into is that, since you have the "captive-bypass" feature enabled, Apple iPhones and iPads won't automatically launch their "mini browser" anymore to open the portal page. This means that users themselves need to open their (regular) browser and manually request a random webpage; big change that will be a https only webpage which will no longer be redirected by the controller. Disabling the "captive-bypass" feature won't help since those same iPhones and iPads won't post their agent information when using the "mini browser", making the on-boarding procedure stop (unsupported device).

Like I said earlier my experience with this on-boarding procedure is a little rusty, but it seems that Cisco has been working on this topic in the meantime. In this document the different options to tackle this issue are documented and also this topic might be informative for you as well. Keep us posted on your findings and good luck!

Please rate useful posts... :-)