Wireless Access

last person joined: 6 hours ago 

Access network design for branch, remote, outdoor and campus locations with Aruba access points, and mobility controllers.
Expand all | Collapse all

Restrict Captive Portal - Internal Database & Bandwidth Contracts

Jump to Best Answer
  • 1.  Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 06, 2014 07:20 PM

    We are using a 3200XM controller running 6.3.1.4. We've got two different SSID's both of whic using Captive portal (No Clearpass). Authentication is the internal database. Let's call one SSID, "Guest" & the other "Employee". What can I do to prevent guests from logging into the crew captive portal and vice versa? The reason we want two seperate SSID's is that we have an upstream device that restricts bandwidth out to the internet based on the VLAN.

     

    The alternative we tried was to combine the two into one captive portal (one VLAN) & then use a different role for "guest" clients and "employee" clients. This works fine for authentication, however it does NOT allow us to restrict bandwidth like we need to. The lowest you can set a bandwidth contract is 256Kb and we need to go lower than that. 

     

    Thoughts?



  • 2.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts
    Best Answer

    Posted Apr 06, 2014 09:04 PM

    If your network is so small that you can combine all of your users into the internal database, you should use a single Captive Portal.  Adding a different SSID just increases wifi contention and does not buy you anything. You cannot go lower than 256k, because even  a 512k bandwidth contract is almost unusable.  I am not sure there is a way to reject users from the internal database based on role.



  • 3.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 06, 2014 10:22 PM

    The reason we've needed two SSID's is so that "employees" & "guests" are in seperate VLANs. If there was a way to reliably assign them to different VLANs while using 1 SSID, then I'd do it. Based on what I've read, clients do not take well to renewing DHCP once authenticated via CP.

     



  • 4.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 10, 2014 09:38 AM

    Any other thoughts or suggestions on this? I'm curious if anyone else has tried to use two different captive portals with one internal database and how they handled roles/permissions.



  • 5.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 10, 2014 09:42 AM

    The internal database is only intended for small deployments with a single captive portal.  There are external options if you have more than one set of users that are trying to get on.  If you have employees, why don't you authenticate them against whatever employee database you have like AD, otherwise, just treat everyone like guests...?



  • 6.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 10, 2014 10:12 AM

    cjoseph, using AD is actually a pretty good idea. We do have a single Server 2012 DC running AD. The majority of the devices are either iDevices or Apple Mac's. Do you think we could still leverage AD authentication for that?



  • 7.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 10, 2014 10:14 AM

    Yes. You can add it as a radius or LDAP server.



  • 8.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 10, 2014 10:43 AM

    I'm definitely going to look into this as an option. I guess I assumed that configuring that would be more trouble than its worth, but it may be the key to geting this ironed out.



  • 9.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 10, 2014 10:48 AM
    You should go all the way and configure NPS with 802.1x for your employees. You don't want them to have their data unprotected.


  • 10.  RE: Restrict Captive Portal - Internal Database & Bandwidth Contracts

    Posted Apr 10, 2014 10:49 AM

    Well, this is a unique environment. it's actually a very large boat. The crew tend to come & go & we need to make adding/removing/changing devices very simple. :-)