I recently installed a dual 7210 controller system at a hotel chain into their first location. For all guest access right now, we are using a single Captive Portal. Everything is working great excep the Captive Portal on certain devices. I was having some problems with Windows XP devices getting CP to display so I made a post in this forum but did not get any further. I called into TAC and they had me switch to a default Captive Portal profile, making only a couple small changes.
Aside from the default profile, I did:
Show AUP (Enabled)
No user logon required (just click Accept)
Enabled HTTP Authentication
And I used a default Server Group (Internal) bc we werent doing any real authentication.
After implementing this slightly modified default CP I had major issues with iOS 6.1.3 and some Windows devices. Here is a description of the problem:
"User joins network; goes to website; redirects to CP but CP does not show anything. (Only blank page is shown, no URL, just says logon in banner or login). This behavior lasts for several minutes until a timeout. The following message is displayed after the timeout, see attached."
So from here I made some more important changes, related to these kb articles,
Enabled hole in logon role out to apple.com (did nslookup for apple ip)
ip access-list session APPLE
user host 188.8.131.52 svc-http permit
user host 184.108.40.206 svc-http permit
also allowed 220.127.116.11 host /32
18.104.22.168 host /32
user role guest-logon
session-acl APPLE position 1
Then created comodo ca cert alias and permitted those IPs on guest-logon:
session-acl comodoca position 2
Yet, still the problem is not fixed. Here is from the customer:
"The captive portal worked fine on my iPad, Dell XPS Win7 this morning. the iPhone didn’t prompt for an authentication and is connected. A Lenovo X300 w/XP worked fine. My Lenovo T400 w/XP (the one that was problematic previously) struggled. The captive portal page loaded once, I clicked accept. I tried to load a web page and it would not. After more than a minute the captive portal page loaded again. A second time I clicked “accept.” Afterwards I was able to load a web page but throughput was sluggish. I disconnected the wireless connection and reconnected. After this performance was normal."
So we have some inconsistency still with the iPhone were sometimes it just doesn't work, and sometimes it allows you on with no prompt for authentication.
Does anybody have any suggestions here?
What part number is your 7000 series controller? The Aruba 7000 series controllers only run on 6.2.x and above...
If you are using http for the captive portal, you should not need to configure anything from those knowledgebase articles. The articles describe what you would need to do if you were using https:
Are you using the ip cp-redirect-address parameter on your individual controllers? What is the default gateway of those guest clients...one of the controllers or a router?
FIrst of all - we are on Aruba 6.2 but the problematic client is on iOS 6.1.3 (not ArubaOS 6.1.3).
Yes, we're using http authentication - so it's safe to remove those ACLs then? They are pointless? I will get you the rest of the informaiton momentarily.
Re-reading your issue clearly now, you DO need the Apple ACL, but it needs to look like this:
config tip domain-name domain.com
<------define a dummy domain
dns-server 22.214.171.124 <---------set a DNS server for the controller to look up addresses
ip domain-lookup <--------- Turn on DNS lookupsnetdestination apple <------Create an "apple" aliasname *.apple.com <------- Make that alias stand for any query that goes to *.apple.comexitip access-list session apple-acl
<------ Create an ACL
user alias apple svc-http permit <------ Make that ACL allow anything to the alias over httpexit
session-acl APPLE-acl position 1 <--------- Apply that ALIAS to your guest-logon role in position one to allow traffic to *.apple.com
If you are NOT doing https: you do NOT need the comodo ACL.
The netdestination dynamically discovers the destination that IOS devices are trying to reach and allows it. This is to prevent the apple CNA activity, which causes issues...
To provide you with the answers to your other questions:
We picked an arbitrary vlan because there needs to be an IP that all clients can reach. That happened to be the vlan interface 192.168.32.3.
The default gateway is on the Cisco Router where dhcp is handed out.
I see where you're going with your post, I guess I just don't see why we wouldn't do it on the 17.x.x.x hardcoded IP address itself. I will give it a shot when I can.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2020 Hewlett Packard Enterprise Development LPAll Rights Reserved.