last person joined: 4 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

Guest access without Captive Portal

Jump to Best Answer
This thread has been viewed 0 times
  • 1.  Guest access without Captive Portal

    Posted Jan 25, 2012 04:12 PM

    I would like to configure guest access, using the ArubaOS, with some tcp/udp ports and bandwidth restrictions, however, I do not want to use a captive portal. So when a guest users connects to the guest ssid, and when they launch their web browser, I want them to go to their home page and not be redirected to a captive portal web page. I thought I had it configured correctly, but when I launch my browser, I'm being redirected to and I get the error web authentication is disabled. 



  • 2.  RE: Guest access without Captive Portal
    Best Answer

    Posted Jan 25, 2012 04:23 PM

    .  Go to Configuration> Security> Authentication> AAA profile.  Find the AAA profile for that WLAN and change the initial role to "authenticated"

  • 3.  RE: Guest access without Captive Portal

    Posted Jan 25, 2012 05:22 PM

    Are those the only three rules? And is DNS actually working (nslookup)? I'm just wondering if you're blocking ICMP, etc. The machine needs to ARP to find the default router, and the firewall has an implicit deny at the end. Also, are you sure you're getting an IP via DHCP and not using a static or 169 address? Seems like you'd also be blocking DHCP. From the CLI on that role it might help to do a 'show rights <role>' so we can have a look at the role. 



  • 4.  RE: Guest access without Captive Portal

    Posted Jan 25, 2012 05:13 PM

    Are you sure that is the role that your client is getting?  Type "show user" and see what role your client is in, and then type "show rights" to see what ACLs are being applied.  If you made a change to the initial role, you need to remove or disconnect the client from the user table for it to get the "authenticated" role.

  • 5.  RE: Guest access without Captive Portal

    Posted Jan 25, 2012 05:09 PM

    Thanks for the quick reply. That worked better, because now I'm not getting re-directed to the captive portal web page. However, my http and https traffic is not working. DNS works fine, because I can resolve DNS names, but the http and https traffic is not making it pass the controller. Would that be a configuration in my guest access policy? I only have 3 rules, but that should be enough to get http and https traffic to work: 

    user -> any -> svc-dns-> permit

    user -> any -> svc-https -> permit

    user -> any -> svc-http -> permit


    Or is there some where else that could be blocking it?  I also tried changing the source from user to any and it still didn't work. 




  • 6.  RE: Guest access without Captive Portal

    Posted Jan 26, 2012 10:55 AM

    DNS is working fine, also with everything else, so I'm not sure why I had the problems yesterday and not today. Maybe after  I changed the initial role, I didn't save the configured, or forgot to disconnected and reconnect. However, changing the initial role to either authentication or my AuthGuest-Role fixed the problem. 






  • 7.  RE: Guest access without Captive Portal

    Posted Jan 26, 2012 11:16 AM

    If it's master local not saving the config could have been the issue. The configuration won't be pushed down to the local until it's saved on the master. Glad it's working for you.





  • 8.  RE: Guest access without Captive Portal

    Posted Jan 26, 2012 11:37 AM
    A disconnect/reconnect may not be all that is needed. If you change an ACL that is used by a role, you have to flush the users from the controllers user table before the change will be noticed by the users. I typically use the "aaa user delete x.x.x.x" command (where x.x.x.x is the users IP address) from the CLI. When you disconnect and reconnect, the user record on the controller most likely doesn't get flushed. It takes a few minutes to notice that the client disconnected. If the reconnect happened before the user record got flushed, it would still use the same ACLs. Thats probably why it didn't work yesterday and does today (the user records would have most likely timed out over night).