Guest Access via Captive Portal - problem with page not always appearing

[cenders]

I have set up a guest wifi network with an access point on an ethernet port of the PAN firewall.  The guest wifi network is unsecured.  I am using a web-form to ensure the guests see our logo, terms, and type in the correct password to proceed.

The setup works most of the time.  On occasion when using this setup via an Apple iOS device (iPhone, iPad) I don't get the portal page and instead receive an error on the idevice, "Hotspot login cannot open the page because the network connection was lost".  I can then only press cancel and it disconnects me from that wifi network.  If I hit cancel and try again, the same problem appears.  When hitting cancel on this the second time, I get presented with "use without internet or use other network".  Now if I click use without internet, and then open Safari and a website I do indeed get the captive portal.

I do not have this problem on any non iOS device (windows laptop, etc).

So, why sometimes does this happen to me?  It is not always repeatable on an iOS device.  I believe this is because the apple device is trying to initially open an HTTPS page.  Does that require me to enable SSL decryption?

[hshah]

Hi Cenders,

Please refer bellow thread, may be that will help you.

Regards,

Hardik Shah

[BobW]

We battle this one quite often.  Here are a couple thoughts:

• The apple devices, when they attach a wireless, automatically call the "success" page (randomdomain/library/test/success.html) on the apple domain.  The idea is nice, because it should autoopen the captive portal page as it tries it's http "success" page call  To get there it chooses from multiple domains.  There is quite a large list, some are shown here:  ios - ios7 and captive portals-changes to apple request URL - Stack Overflow.
• Having said that, I have found that even minor changes in the OS act differently.  (example not necessarily correct) IOS 6.01 works, 6.02 doesn't, 6.03 works sometimes etc.
• As I recall, the primary issue is related to Safari.  I had a case with Palo Alto where we did packet captures, etc and Safari would try to get out but would never get any packets back.  As I recall, we never did figure out why.
• Firefox and Chrome work without a problem.

So what I ended up doing is

• Creating a rule to allow unknown user access to the apple subnet and the success page.  Effectively disabling the captive portal auto prompt.
• Made it clear to my users that if they have an issue with IOS devices, try using a browser other than Safari and it will work every time and they will not get any email, or apps, functioning until the open a browser window.
• When they open safari or chrome, make sure to go to an http page.  Google, for example tends to default to https.

I may not have the above 100% as it has been a while, but hopefully that will give you some starting points.

Bob

[Tijl]

Are you using a public certificate on your captive portal page?

If so, you will need to allow 'unauthenticated' CRL and OCSP checks to the CA of the certificate.

The exact URL's you need to allow are in the certificate.

[cenders]

That link seems to be restricted, I can't open it.

[hshah]

Hi Cenders,

Sorry about that, please find the solution which I wanted to provide. Let me know if this helps.

"The way to get this to work is to whitelist the Apple URLs meaning exclude the list of Apple URLs that the iPad needs to connect to, from the CP policy

That the ipad can reach its apple specific urls and the user's ipad can work

For other websites, the user's will still have to rely on traditional CP

The way Cisco / Aruba / etc address this through their WLAN authentication is not currently supported in PAN"

Regards,

Hardik Shah

[cenders]

tijl,

I like the train of thought there, so I added a no-captive-portal rule in my Captive Portal policies for the CRL and OCSP URLS.  Is that the only place I need to add it, or does it also need to be a security rule?  I've only added it to Captive Portal policies, above my existing CP rule but no luck.  For what its worth, the problem I am having is not consistent. I have an ipad that works most of the time and another one that does not most of the time.

I also can't understand why I'm not seeing something being blocked in the logs while troubleshooting this.

As I've mentioned, this problem only seems to happen after joining the wifi and the CP page auto-opens.  If I cancel a few times and say "use without internet", then I can launch Safari, try an HTTP website and the captive portal correctly appears. If I try an HTTPS website initially then nothing loads.

[cenders]

If I whitelist all of Apple's "success" URLs, which will cause the device to correctly connect to the WIFI, then if the user never opens Safari (and for example opens the mail client) then I'm guessing that they won't be able to check for mail...

[cenders]

Bob, good band-aids but I'm looking for a proper solution.  ie: the CP page should open correctly when joining the wifi, plain and simple.

[cenders]

I have also tried an SSL Decrypt rule for that traffic and it doesn't work.

[BobW]

"Bob, good band-aids"

Agreed.  As I say it seems to work 100% with Firefox and Chrome.  I truly believe it is an apple issue given it works different depending on the revision.

Please keep us updated if you find a solid fix!

Bob

[Tijl]

Hi Cenders,

You will also need a security rule. You'll need to allow this regardless of the browser or OS used.

The iOS behaviour with a captive portal depends on the iOS version. What version are you currently having issues with?

Tijl

[cenders]

Tijl, I think the problem started with iOS 7 and anything above.  Current iPad I'm testing with is running 8.1.3.  I do have security rules related to the captive portal, such as allowing DNS without requiring identity and regular http and https traffic for "known users" (which forces the CP).  I have a captive portal rule with "web-form" as the action for http and https.  I think the setup is fine as I don't seem to have a problem with windows based computers going through the CP.

[cenders]

Hardik, I don't want to whitelist the Apple URLs because I want the Apple device to correctly open the CP upon trying to join the Wifi network.  I have seen other CP solutions work just fine with Apple devices, I'm lost trying to figure out why it isn't working 100% with Palo Alto.

[cenders]

Tijl, along the lines of your thinking with regards to HTTPS, I have read elsewhere that Apple's "Captive Network Assistant" has issues where the portal is HTTPS.   Apple's initial HTTP GET request (for the success.html) then being redirected to an HTTPS captive portal is the problem here.  But who in their right mind would have a captive portal that isn't HTTPS?   I guess if I use wifi isolation (preventing wifi clients from talking to each other) could a sniffer still see plain text credentials of the portal?  It would be easy to then sniff the portal password from other clients.