Product and Software: This article applies to all Aruba controllers and APs and all ArubaOS versions.
Normally, when you implement captive portal for guest users, you need only these ACLs in the initial role:
!
ip access-list session captiveportal
user alias controller svc-https dst-nat 8081
user any svc-http dst-nat 8080
user any svc-https dst-nat 8081
user any svc-http-proxy1 dst-nat 8088
user any svc-http-proxy2 dst-nat 8088
user any svc-http-proxy3 dst-nat 8088
!
ip access-list session logon-control
user any udp 68 deny
any any svc-icmp permit
any any svc-dns permit
any any svc-dhcp permit
any any svc-natt permit
!
user-role logon
session-acl logon-control
session-acl captiveportal
captive-portal default
!
So, when the wireless guest users connect to an open SSID, they fall in the above mentioned Role "Logon" (Initial Role of AAA Profile).
When the Windows devices, iPads, and iPhones with iOS versions less than 5.x browse the Internet, their traffic is destination NATed to the controller, and they get the captive portal page successfully.
Behavior of iOS Devices 5.x and Later
If the Apple devices with iOS 5.x and later tries to browse the Internet, they first go to the website "www.apple.com" and the reply must come from the apple.com website.
If the reply does not arrive from the apple.com website, the iOS 5.x devices (like iPad or iPhone) are unable to get the captive portal page successfully. Apple does this for security reasons.
Prior to iOS 5.x, Apple devices do not have this feature, and they do not need any extra ACLs to be added to the initial role where they are falling in and they successfully get the captive portal page.
How Devices with iOS 5.x and Later Get the Captive Portal Page
You have two methods to make it work.
Method 1
Allow an http connection to apple.com before the "captiveportal" acl as follows:
Do a nslookup on any devices on your network and get the apple.com's IP address.
Then allow any svc-http transactions to that particular ACL as follows:
!
ip access-list session APPLE
user host 17.149.160.49 svc-http permit
user host 17.172.224.47 svc-http permit
!
Then map this APPLE ACL on top of the user-role logon as follows:
!
user-role logon
session-acl APPLE position 1
!
After you do that, the http request to the apple.com is permitted, the Apple server returns a reply, and the iOS 5.x devices proceed to the next step and get the captive portal page successfully.
Method 2
If the Aruba controller has ArubaOS 6.1.x and later, you have more flexibility to permit apple.com in the Initial role.
You can create a whitelist and map the it to the captive-portal profile as follows:
!
netdestination APPLE => any meaningful name
name apple.com => mapping the apple.com website
!
aaa authentication captive-portal default
whitelist APPLE
!
ip domain lookup
!
ip name-server <dns-server ip address> => Enter the IP address of the DNS Server.
!
In this configuration, if you map the apple.com website as a whitelist for the captive-portal Profile, you allow the http requests to apple.com websites successfully.
One advantage of using this whitelist method is that you do not need to know the IP address of the apple.com server.
The controller dynamically finds it because you enabled domain lookup and mentioned the DNS server.
Limitation: This method is applicable if you have ArubaOS 6.1.x and later.
Using these two methods, you can make the iOS 5.x devices get the captive portal page successfully after they open the webpage.