Aruba controllers support various methods for preventing the Captive Network Assistant (CNA) from popping up in Apple devices when they associate to open SSIDs that run captive portals. These methods include using a whitelist entry against the domainwww.apple.com or using CPGuest (formally Amigopod) to present a modified landing page that specifically looks for the Apple devices attempt to check if they are behind a captive portal.
More information about the workings of the Apple CNA can be found in the following tech note http://www.arubanetworks.com/wp-content/uploads/Amigopod-CNA-bypass-AppNote.pdf
During internal testing of iOS 7, it was found that Apple has modified the behaviour of the CNA which affects the various workarounds already in place. The impact of this is that the iOS 7 device will no longer proceed directly to the controller hosted captive portal (or CPGuest) rather it pops up the Apple CNA screen. The key changes are:
- device no longer attempts to contact http://www.apple.com/library/test/success.html
- device now cycles through a list of various websites to achieve same functionality
ArubaOS 6.3 is able to automatically handle both the new behaviour of iOS7 and the older behaviour if the configuration optionapple-cna-bypass is enabled in the captive portal profile.
Previous versions of ArubaOS do not support this functionality and rely on whitelisting in either the captive portal profile or the captive portal access control list (ACL) in order to allow the client device to reach the Apple CNA website freely. Typically this means the fully qualified domain name (FQDN) www.apple.com is added to a network destination (netdestination) which is then added to the captive portal profile white-list. Depending on the version of ArubaOS, the captive portal profile may not yet support white-list, in that case the netdestination can be added to the ACL which is applying the captive portal redirection, specifically by creating allow rules above the captive portal dst-nat rules.
In order to handle iOS7 devices, the following FQDNs need to be added to a netdestination and then added to the captive portal white-list. Note that they could also be added to any existing netdestination that may be in place for earlier Apple devices. These FQDNs have been determined from sniffing the traffic generated by an iPhone running iOS7, the list may be longer and/or subject to change in the future.
- captive.apple.com
- www.airport.us
- www.ibook.info
- www.thinkdifferent.us
- www.appleiphonecell.com
- www.itools.info
Sample configurations
The below config assumes the captive portal profile is called captiveportal and creates a network destination called apple-cna. In this example the FQDN www.apple.com is also added to take care of pre iOS7 devices.
conf t
netdestination apple-cna
name www.apple.com
name www.airport.us
name www.ibook.info
name www.thinkdifferent.us
name www.appleiphonecell.com
name www.itools.info
!
aaa authentication captive-portal captiveportal
white-list apple-cna
!
The next example shows the use of an ACL rather than the captive portal profile white-list. The two methods are identical in outcome however the captive portal white-list is easier to configure. The config below assumes that there is some user-role being used as the initial-role which uses an ACL called captiveportal which is configured for either internal or external captive portal but has no other 'permit' rules added to it.
conf t
netdestination apple-cna
name www.apple.com
name www.airport.us
name www.ibook.info
name www.thinkdifferent.us
name www.appleiphonecell.com
name www.itools.info
!
ip access-list session captiveportal
user alias apple-cna svc-http permit position 1
!
Note that the ACL must appear at position 1 - or at the very least above the dst-nat based captive portal rules otherwise the http request from the Apple device to the relevant CNA website will always be captured by the controller captive portal, and the CNA will always pop up on the screen.