Security

last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

Centralized Guest Access in a local(s)-master-hotstandby scenario

This thread has been viewed 1 times
  • 1.  Centralized Guest Access in a local(s)-master-hotstandby scenario

    Posted Sep 27, 2012 09:17 AM

    Hi all, I'm new to this forum. I wonder if someone here can help me. The theme here is Centralized Guest Access in a master-standby scenario

    The structure I'm dealing with is composed by a main-site and many remote-sites: at the main-site there are two controllers, the master controller and the hot-standby controller.

    At each remote site there is one local controller.

    I need to deploy a centralized guest access solution.

    This is what i did:
        1) On the master controller I've created interface vlan 4000 with ip 172.16.0.254/24: this is the default-gateway for all guests accessing from whatever remote sites.
        2) On the master controller I've created an "ip dhcp pool vlan4000" to assign ip addresses tu guestes
        3) I've defined one GRE tunnel between each local controller and the master controller; each tunnel is configured to transport vlan 4000

    This is what it's working:
        1) a guest is allowed to associate to wlan "Guests" in whatever remote site, it obtains an IP address from the dhcp pool defined on master controller and can ping the default gateway at 172.16.0.254  

    This is the help I need to complete
        1) authenticating the guest via integrated Captive Portal:
            - which is the actual controller that authenticates guest users? master or locals?
            - which is the internal user database I have to popolate? master or local?        
        2) NATTING guests before routing them to Internet:
            - I'd need some help in configuring NAT, but this is the simples tip...
         3) Redundancy. This is the most difficult tip to me.
            - How have I to manage GRE Tunnels? Do I need a couple of GRE Tunnel between each local controller to both master.controller and hot-standby-controller?
            - Have I to use VRRP on interfaces vlan 4000 (on master and hot-standby)? If yes which is the physical interface vrrp works on? If not which is the way to assure guest access in case of a master failure?  

    If needed I can prepare and attach a drawing.

    Thanks in advance.

     



  • 2.  RE: Centralized Guest Access in a local(s)-master-hotstandby scenario

    Posted Sep 27, 2012 09:35 AM

    1) By default the master will do the auth for your guest users. This can be changed if needed. 

     

    2)Take a look at the users guide for how to setup nat.   Do you have a separate internet connect for your guest user traffic or are you going to nat it and send it out to your primary internet circuit? Might want to attach the diagram so we know how guest user traffic is going to flow.

     

    3)I would setup a VRRP address which will "float" between the he controllers if the active master goes down then the stand-by will pick up the address the tunnel will now be on the stand-by. 



  • 3.  RE: Centralized Guest Access in a local(s)-master-hotstandby scenario

    Posted Sep 27, 2012 10:28 AM

    Hi ddipert, thanks for your answers.

    1) I want the master to authenticate my guests: what about the database? I understand that I must fill the dB on Master, leave blank the dB on local(s). Have I to duplicate dB entries in hot-standby or there's a sort of "syncronization"?

     

    2) Both master and hot-standby controllers have two interfaces: one "Internal" and one "External". The "Internal" runs VRRP and downside connections to local(s) controllers (it's the interface that face to MPLS network...). The "External" is connected to Internet. On "External" interfaces actually I don't run VRRP.

     

    3) Ok. The VRRP is still running and working: if I use the "Internal" VRRP logical address as a destination tunnel address on each local controller I make tunnels working even in the case of a master failure. That's ok. What it doesn't make sense is the way I have to manage the redundancy on interface vlan4000 that's actually not bounded to any physical port.  At the moment I've created this interface only on the master controller and I use it as a default  gateway for guests. In case of a master failure all GRE tunnels would correctly be terminated on VRRP "Internal" address but what would happen to guests default-gateway?

     

    Hope this help to explain my headache.

     



  • 4.  RE: Centralized Guest Access in a local(s)-master-hotstandby scenario

    Posted Oct 26, 2012 01:19 PM

    1- By default the master will authenticate your captive portal requests, assuming the server group in the captive portal contains the server 'Internal'. You do not need to populate the database on the locals. The local-userdb DB will synchronize with the master standby as long as this command is present on the active master: 'database synchronize period 30' (You can use a value other than 30. This is the sync interval in minutes.)

     

    2- On the VLAN interface where your guest users receive an IP address you will need the statement 'ip nat inside'. You do need any NAT statements on your physical inside or outside interfaces.

     

    3- I'm not sure I'm seeing the need for the static GRE tunnels you created. The local controllers communicate with the master controllers via IPSec tunnels. If you create a VRRP instance for VLAN 4000, make the VIP 172.16.0.254, make sure that IP is the default gateway defined in your DHCP scopes, that should be fine. Remember to create the scopes on both your master controllers, and i would recommend splitting the scopes so the master-pri hands out IPs in the lower portion of the network, and the master-stby hands out IPs in the upper portion. This will help with potential duplicate IP addresses during failover. Occasionaly a client will not release it's IP (although it should)