Captive Portal Drops the Connection for iOS Devices
Resolution
Cause
When connecting an iOS device to wifi, it will automatically start making several outbound connections to services on the domains listed below. If captive portal is configured these connections will trigger captive portal redirects but these will not be visible to the user as the conenctions are made in the background. To prevent overtaxing the Captive Portal service, the number of connections to the service is limited per source. This could cause a legitimate safari connection to remain blank for a while, until the background connections time out and more CP threads are made available to the client.
Resolution
To prevent the user from getting a blank screen or long load time, you can whitelist the below listed domains.
Android Captive Portal Detection:
Domain names to white list:
clients3.google.com
iOS 6:
Domain names to white list:
gsp1.apple.com
*.akamaitechnologies.com
www.apple.com
apple.com
iOS 7:
Domain names to white list:
www.appleiphonecell.com
*.apple.com
www.itools.info
www.ibook.info
www.airport.us
www.thinkdifferent.us
*.apple.com.edgekey.net
*.akamaiedge.net
*.akamaitechnologies.com
Then create a no captive portal rule and keep this on top of the existing captive portal rule.
Commit the changes and attempt new connections from the iOS devices.
It will still prompt the iOS user to enter user credentials from their default Safari browser when their device connects to your network, and enforce the Internet access policy of that user base on his/her AD security group membership.