Security

Hello,

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, 

https://arubanetworkskb.secure.force.com/pkb/articles/Troubleshooting/R-1314

https://arubanetworkskb.secure.force.com/pkb/articles/HowTo/R-1680

Enabled hole in logon role out to apple.com (did nslookup for apple ip)

 ip access-list session APPLE

user host 17.172.224.47 svc-http permit

user host 17.149.160.49 svc-http permit

also allowed 17.173.254.222 host /32

 96.16.237.15 host /32

 23.1.172

user role guest-logon

session-acl APPLE position 1

Then created comodo ca cert alias and permitted those IPs on guest-logon:

199.66.201.169

 host 91.209.196.169

 host 170.255.83.1

user role 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.

Okay.

Re-reading your issue clearly now, you DO need the Apple ACL, but it needs to look like this:

config t
ip domain-name domain.com
   <------define a dummy domain

dns-server 8.8.8.8  <---------set a DNS server for the controller to look up addresses


ip domain-lookup  <---------  Turn on DNS lookups
netdestination apple  <------Create an "apple" alias
name *.apple.com   <-------  Make that alias stand for any query that goes to *.apple.com
exit
ip access-list session apple-acl
  <------  Create an ACL

user alias apple svc-http permit  <------  Make that ACL allow anything to the alias over http
exit

user role guest-logon

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.