Security

last person joined: 23 hours ago 

Enterprise security using ClearPass Policy Management, ClearPass Security Exchange, IntroSpect, VIA, 360 Security Exchange, Extensions and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

More Captive Portal Issues (iOS 6.1.3, Win XP)

  • 1.  More Captive Portal Issues (iOS 6.1.3, Win XP)

    Posted Apr 23, 2013 05:02 PM
      |   view attached

    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?

     


    #7210


  • 2.  RE: More Captive Portal Issues (iOS 6.1.3, Win XP)

    Posted Apr 23, 2013 05:40 PM

    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?

     



  • 3.  RE: More Captive Portal Issues (iOS 6.1.3, Win XP)

    Posted Apr 23, 2013 05:55 PM

    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.



  • 4.  RE: More Captive Portal Issues (iOS 6.1.3, Win XP)

    Posted Apr 23, 2013 06:04 PM

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

     

     

     

     



  • 5.  RE: More Captive Portal Issues (iOS 6.1.3, Win XP)

    Posted Apr 23, 2013 07:03 PM

    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.