WLC and ISE Captive portal with IOS devices

[Males]

Hi

I am running into a strange issue and before I open a ticket on the matter with TAC, I thought I'd ask the community for hints as to what may cause the problem.

I have a hotspot-style captive portal configured and it works fairly well with an Iphone 7+, a windows laptop, a mac laptop and android devices of all kinds.

I also happen to have an iphone 5 and an iphone 7---which won't work "AT ALL". That is to say that I can see that the URL redirection works, but the CNA doesn't open, and no other url will redirect to the portal. I even tried pasting the url my WLC says it's sending to the client and it will not load.

It's not a DNS issue because I get this even if I try an IP.

It's not because it can reach the CNA's apple url, because it cannot (I tried it on the device, and remember I also have an Iphone 7+ which works...)

I am running ISE 2.3 p1, and 8540s under 8.2 MR7.

I can see that the client is assigned the redirect regardless of platform.

However on the IP5 and IP7, the CNA will not open. Copying and pasting the url will not work either.

Out of ideas...help?

Tried something with an ip, or replacing the dns name of the psn for the ip to no avail.

[ammahend]

I am not sure what’s the solution but it points to MTU issue, had a smililar issue, will be be possible for you to adjust th MTU and test it out. 

Since APs do not support jumbo frames, in a test environment try setting it to max supported size on your respective AP.

[Males]

Hi

thank you for your answer. The thing that makes me doubt it has to do with MTU is that it works with IPhone 7 +, but not iPhone 7.

Aslo read a lot of contradictory information about whether or not to have captive-bypass detection disabled or enabled.

[Rich R]

Hi Males

You mention the iPhone models but not what version of iOS they are running.

A common problem with all captive portals is progressively increasing security levels on browsers and operating systems.

1. Captive portals often rely on self-signed certificates which can be a problem

2. When captive portal is redirected from an https page most OS and browsers will now block that because the certificate doesn't match the original domain.

Since you say you can't even open the redirect URL directly that suggests 2 is not the problem but 1 could still be.

So:

- Compare iOS versions

- Compare any/all security settings in iOS and browser, and try different browsers as some give more detailed messages about why they've blocked something (and turn off 'friendly' error messages if that is an option because it hides the real error).  Sometimes it can even be because some of the content in the page is not secure.

- Make sure your portal is using a valid public certificate not a self-signed cert.

- Sometimes doing a Reset all settings magically fixes strange problems like these on iPhones.

Hope this helps ...

Rich

[ammahend]

perform a capture and see if you are getting a lot of re-transmission, that might be an indication of what I am suspecting here.