"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!
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, 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.
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.
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.
I had a similiar issue to where the Captive Portal would display some of the time and I would get the generic browser error page at other times. Long story short, the Captive Portal interface has a config setting for a threshold as to the number of attempts an IP can make to it within a certain period of time. For me, it was 1 request every 2 seconds. We upped this to something like 3 requests every second and the problem went away.
The problem in my case was that when a system came on the network and the user begins typing in their search parameter in the browser bar, the browser would perform a kind of prefetch function for the content as they typed it in. These requests were being sent to the CP and causing it to hit its threshhold. Sebsequently, by the time the user presses enter, they would get the generic browser error page about the resource not being able to be reached instead of the CP due to the CP dropping the request.
Hope this helps...someone.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!
The Live Community thanks you for your participation!