Cat9800 captive portal bypass for Apple devices

[KevinR99]

Hi

I've seen various discussions about this but none seem to fix my issue. 

I have an SSID that redirects perfectly well with Windows and Android.  However, Apple devices don't play.  I usually get redirected to the login portal and log in successfully.  When I look on the WLC the client is in Run state.  However, the apple client never goes to my Success URL or success page.  Usually the mini browser just disappears and I am no longer connected to the SSID.  Sometimes the mini browser just sits there with a white screen.  If I close it and reconnect to the SSID I am on and can browse.  This isn't ideal.  So I am looking at the captive portal bypass feature.  Since this is a Cat9800 and not an AireOS controller it's applied differently.  As far as I can see it needs to be applied via a named Web auth parameter map by ticking Captive Bypass Portal.  So I do this and the only place I can apply it is in the Layer 3 security section of the SSID.  When I do this my non-Apple devices are still ok.  On Apple devices the SSID profile is connected and says No Internet access.  So I fire up a browser in the hope that it will be intercepted and redirected to my Guest portal but it doesn't.  Have I missed something in the WLC to get the portal bypass to work ?

Thanks, Kev.

[Rich R]

Never used captive-bypass-portal before myself so can't comment on how well that does or doesn't work, but presumably you'd rather have the captive portal working correctly?
What version of software are you using?
Have you run debug/packet capture/radioactive trace on a client experiencing the problem?
Are you using valid public certificates for your portal(s) which match the DNS FQDN of the site?
How do your configs look at the moment?

[KevinR99]

Rich, Arshad

I am only in a lab environment so I don’t have a public certificate for the splash page.  I use one generated by one of our internal CA’s but will install a public one in the live solution.  I have run a radioactive trace on the client but it produces a lot of output which is very time consuming and difficult to plough through without knowing what I’m looking for.  What I can see is the redirect URL being sent back but as far as I can see in those lengthy logs that gets repeated with nothing else to give me a clue as to what the client is doing.  I do redirect to a URL which is resolvable by our DNS and as a test I have applied a static IP to the Authz profile on ISE.  I am running IOS-XE 17.7.1 and ISE 3.1 patch 1 I think.

Thank you for your input, Kev.

[Rich R]

If iOS doesn't trust your cert, which it won't unless you've installed your CA as trusted, then it won't popup the portal, plain and simple.
Unless you have a very specific reason you shouldn't ideally be using 17.7.1 - it's a short-lived release which won't get any bug fixes.  Think about using an extended support release - 17.6.4 or 17.9.1 (17.9.2 should be out soon).  Refer to TAC recommended releases link in my signature.

[Arshad Safrulla]

What is the code you are running? Do you have http enabled under web auth parameter map or the ip http server?

If captive portal bypass enabled APPLE device will completely ignore it's captive portal detection mechanism (WLC replies to APPLE device with expected parameters, so APPLE device thinks there is no captive portal), this is recommended when you have CWA or any 3rd part Captive portal integration is in place. Keep in mind, here APPLE will not auto prompt the mini browser.

If you disable captive portal bypass, then WLC will not intercept the captive portal detection mechanism of APPLE device. So by default, you will be prompted the portal using APPLE mini browser. 

I personally prefer keeping it disabled as it provides good experience to the user, rather than manually opening the web browser. But if you really need to get the redirection URL's working, I will prefer to have it enabled. 

parameter-map type webauth global
type webauth
virtual-ip ipv4 192.0.2.1
virtual-ip ipv6 2001:DB8::1
webauth-http-enable