Controller Based WLANs

How do I redirect guest access across a GRE tunnel to a DMZ network?

by on ‎07-09-2014 12:54 PM

Product and Software: This article applies to all Aruba controllers and ArubaOS versions. 

The intent of the design is to redirect all guest traffic from the first hop Aruba controller out to the DMZ across a GRE tunnel. Because traffic is brought into the first hop Aruba controller by a dynamically built GRE tunnel from the AP and then redirected out to the DMZ across a similar tunnel, the guest users’ frames (or packets) are never exposed to the internal network. The following benefits are realized by this design: 
•     Guest are now virtually on the DMZ and are treated as any other untrusted device on the Internet. 
•     The Aruba overlay model means that no costly network changes are needed to isolate the guest WLAN. 
•     Centralized configuration and control of guest policies provides centralized monitoring and logging of guest access. 

Required Hardware 
The design assumes three Aruba controllers, one master controller, one local controller, and one controller on the DMZ (stand-alone and not part of the master/local cluster). It should be noted that the functions on the master and local controller may be combined into the same controller; the separation was made in this configuration guide to show how the guest policy can be controller and managed by the master controller regardless of the number of local controllers in the network, thereby easing management and providing a scalable model to work from. 

One other important aspect to note is that the device that terminates the GRE tunnel in the DMZ does not have to be an Aruba controller. Any device can be used that can terminate GRE and forward Ethernet (extend a VLAN) across the tunnel. For the sake of this design guide, an Aruba controller was used.  

Design Guidelines 
Network Configuration 
It is assumed that a working Aruba WLAN is in place today with either a single controller or a cluster of controllers with a master/local hierarchy. All configuration steps will be made in reference from the master controller (unless otherwise noted). In a single controller topology, the steps for the master and the local controller are combined onto the single controller.

Guest VLAN 
The VLAN that the guest users will be placed on and get an IP address from should be nonroutable in the internal customer’s network. This VLAN can be an isolated private (RFC 1918) VLAN created on the local controller or can be a VLAN that resides on the DMZ that is logically extended to the local controller through the GRE tunnel. 

The following are design considerations for each approach: 
•     An “isolated guest VLAN” can be provisioned across the local Aruba controllers and extended out to the DMZ through a GRE tunnel. In most cases this guest VLAN will be provisioned from private RFC 1918 space and will be both non-routable in the existing customers’ network as well as non-overlapping any customer address space used on the internal network. Since this private VLAN will be logically extended out to the DMZ, some device will need to NAT the source addresses of the Guest users packets before being routed to the Internet. This is the design that this document will primarily focus on. 
•     A “DMZ VLAN” can be extended to the local Aruba controllers through the GRE tunnels. In this design, it is likely that this DMZ VLAN is public IP space owned by the customer for use on their DMZ. This design may overcome any concerns with overlapping the use of the RFC 1918 address space as well as removing the need for NAT, but could pose a concern for the size of the space available for handing out guest users’ addresses.   

WLAN and SSIDs 
This document will describe how to configure the ‘guestnet’ SSID. 

Guest Authentication 
Guests authenticate using a web browser through Aruba captive portal authentication. The users’ credentials are gathered using this web page and are presented to a backend database for verification of a users access privileges. This backend database can be an LDAP, RADIUS, or an internal Aruba user database. For the purposes of this document, the internal Aruba database will be used. It should be noted that the Aruba internal user database is stored on the master Aruba controller. The ability for the local Aruba controllers to reach the master Aruba controller as well as a redundant design being implemented for the master controller is assumed.   

Installation Procedure 
Follow these steps:

1)     Configure a guest VLAN on local controller and DMZ controller. 
2)     Configure GRE tunnels between DMZ and local controllers. 
3)     Configure the DMZ controller. 
        a)     Configure guest DHCP services. 
        b)     Configure guest ‘NAT’ policy. 
        c)     Lock-down DMZ controller. 
4)     Configure guest authentication. 
        a)     Configure guest ‘pre-logon’ policy on master controller. 
        b)     Configure guest ‘post-logon’ policy on master controller. 
        c)     Configure rule to force guest users into ‘pre-logon’ policy. 
        d)     Configure captive portal redirect address on local controllers. 
5)     Configure SSID. 
6)     Setup guest accounts on master controllers’ internal database. 
7)     Scale the solution. 

Configure a Guest VLAN 
Set up a guest VLAN that is a private (RFC 1918) subnet that does not overlap with any existing customer address space and will not be redistributed as part of the customers’ Intranet. The following address space is used throughout the rest of the document:  
- 172.16.0.0/11 = Intranet address range 
- 192.168.0.0/16 = Guest address range 
- 64.64.64.0/24 = DMZ address range 

Configure the following guest VLAN on the DMZ and local controllers only:    
(dmz) (config)# vlan 4094    
(dmz) (config)# interface vlan 4094   
(dmz) (config-subif)# ip address 192.168.0.1 255.255.0.0
   

This will be the guest users default gateway.      

(local) (config)# vlan 4094   
(local) (config)# interface vlan 4094     
(local) (config-subif)# ip address 192.168.0.2 255.255.0.0   

Each local controller will be given an IP address in the guest range, which is needed for captive portal redirection to the local controller. A block of addresses will be reserved from the DHCP pool for this allocation.    

Configure GRE Tunnels 
This section describes how to configure a static GRE tunnel from the DMZ Aruba controller to the local Aruba controller(s). This configuration can be repeated for as many local Aruba controllers as required.  

Note: It is important to ensure that the tunnel IDs on the local Aruba controllers are always the same. For example, if you use 100 on one, you should use 100 on the others. This is important so that a guest access policy can be configured globally to match tunnel ID 100, for example. The tunnel ID on the DMZ controller does not need to match the tunnel ID on the other end of the tunnel and can be assigned sequentially. To configure this step, you will need to know the tunnel’s source and destination IP address. 

For the purposes of this document, the controllers have the following IP addresses: 
DMZ controller = 64.64.64.254 
Local controller = 172.16.0.254 
Master controller = 172.16.1.254        

Configure the following GRE tunnels on the DMZ and local controllers only:    
DMZ Controller:   
(dmz) (config)# interface tunnel 1    
(dmz) (config-subif)# tunnel source 64.64.64.254    
(dmz) (config-subif)# tunnel destination 172.16.0.254    
(dmz) (config-subif)# tunnel vlan 4094   
(dmz) (config-subif)# no trusted
    

Set the DMZ side tunnel to ‘untrusted’ to force guest users into the ‘logon’ role. The ‘logon’ role on the DMZ controller will be used to NAT the guest user traffic.   

Local Controller:     
(local) (config)# interface tunnel 100    
(local) (config-subif)# tunnel source 172.16.0.254    
(local) (config-subif)# tunnel destination 64.64.64.254    
(local) (config-subif)# tunnel vlan 4094    
(local) (config-subif)# trusted  
   

Test the tunnel by attempting a ping, from each controller, to the other controllers’ guest VLAN IP address. Ensure that appropriate firewall rules have been opened between the DMZ controller and the local controller. You can check the state of the tunnel with the following command (note that the tunnel is ‘up’ and the line protocol is ‘up’):     

(dmz) # show interface tunnel 1   

Tunnel 1 is up line protocol is up 
Description: Tunnel Interface Source 

Source 64.64.64.254 
Destination 172.16.0.254 
Tunnel is a Layer2 GRE TUNNEL 
Tunnel is UnTrusted Inter 
Tunnel Flooding is enabled 
tunnel vlan 4094 

Configure the DMZ Controller   
The DMZ controller sits on the DMZ and accepts guest traffic off of a GRE tunnel from a local controller and forwards that traffic onto the DMZ for forwarding to the Internet. In this sample design, the DMZ controller issues DHCP addresses to the guest users and NATs the guest users’ traffic onto the DMZ. By configuring the DMZ controllers tunnel interface as ‘untrusted’, all guest user traffic falls into the ‘logon’ role by default. The ‘logon’ role is used to NAT the user traffic. Also, as with any device residing on a DMZ, it is important to ensure that the device is locked down to prevent unauthorized access or use. The following steps provide the details for accomplishing these design goals.   

Configure DHCP services on the DMZ controller:     
(dmz) (config)# ip dhcp pool guestnet    
(dmz) (config-dhcp)# network 192.168.0.0 255.255.0.0    
(dmz) (config-dhcp)# lease 1 0 0    
(dmz) (config-dhcp)# default-router 192.168.0.1   
(dmz) (config-dhcp)# dns-server 100.100.100.1    
public DNS server or one on DMZ deemed suitable for use by guest users   

(dmz) (config-dhcp)# authoritative   
(dmz) (config-dhcp)# exit   
(dmz) (config)# ip dhcp excluded-address 192.168.0.1 192.168.0.255  range reserved for local controller addresses on guest VLAN   
(dmz) (config)# service dhcp    

Configure NAT pool on DMZ controller:     
(dmz) (config)# ip NAT pool guest-nat 64.64.64.254 64.64.64.254    

Configure policy to NAT guest traffic on DMZ controller:     
(dmz) (config)# ip access-list session guest-nat      
(dmz) (config-sess-guest-nat)# any any svc-dhcp permit       
(dmz) (config-sess-guest-nat)# any any any src-nat pool guest-nat
    

Configure the ‘logon’ role on the DMZ controller to use the ‘guest-nat’ policy:     
(dmz) (config)# user-role logon   
(dmz) (config-role)# no session-acl control    

If the system is in the default state, the following default policies need to be removed from the ‘logon’ role.    
(dmz) (config-role)# no session-acl captiveportal    
(dmz) (config-role)# no session-acl vpnlogon    
(dmz) (config-role)# session-acl guest-nat    

Configure policy to block nonestablished session to or through the DMZ controller:     
(dmz) (config)# netdestination dmzcontroller    
first create alias to use in policy 

This will help when more local controllers are added to the solution. Instead of policy changes, only changes to the aliases are required. 
   
(dmz) (config-dest)# host 64.64.64.254    
(dmz) (config-dest)# exit   
(dmz) (config)# netdestination controllers    
(dmz) (config-dest)# host 172.16.0.254    
(dmz) (config-dest)# exit   
(dmz) (config)# ip access-list session port-policy   
(dmz) (config-sess-port-policy)# alias controllers alias dmzcontroller svcgre permit   
allow GRE to/from local controllers and the DMZ controller  

(dmz) (config-sess-port-policy)# any any any deny    
This will block anything else from getting into or through the Aruba DMZ controller. Guest user traffic is allowed through due to the fact that it was established through the ‘guest-nat’ firewall policy applied to the guest user traffic above.    

Bind port-policy to the port connecting to the DMZ:     
(dmz) (config)# interface fastethernet 1/0    
(dmz) (config-if)# trusted    
(dmz) (config-if)# ip access-group port-policy session
     

Configure Guest Authentication and Policy Enforcement 
This step configures all the necessary policies and rules needed to force a guest user through the Aruba captive portal guest authentication page and to grant certain access rights after they authenticate. The pre-authentication policy allows basic services like DHCP, DNS, and ICMP, redirects all HTTP and HTTP traffic to the captive portal, and drops anything else. After the user authenticates, the guest users’ role changes to allow a limited amount of Internet services. For all traffic in both roles, other than local authentication traffic, the users’ frames are redirected directly out to the DMZ. The following rules are configured ‘globally’ on the master controller and are dynamically pushed to all local Aruba controllers. No further policy changes will be required on the local Aruba controllers. 

Configure common alias to be used in policy creation on master controller:   
(master) (config)# netdestination guestcontrollers   
(master) (config-dest)# host 192.168.0.2    
add all local controller guest VLAN IP in this alias   

(master) (config)# netdestination guestusers 
(master) (config-dest)# network 192.168.0.0 255.255.0.0       
Configure common alias to be used in policy creation on master controller:     
(master) (config)# netdestination guestcontrollers   
(master) (config-dest)# host 192.168.0.2    
add all local controller guest VLAN IP in this alias   

(master) (config)# netdestination guestusers   
(master) (config-dest)# network 192.168.0.0 255.255.0.0
      

Configure guest ‘pre-logon’ basic services policy on master controller:     
(master) (config)# ip access-list session guest-control   
(master) (config-sess-guest-control)# user any udp 68 deny
   
blocks a guest user from being a DHCP server     

(master) (config-sess-guest-control)# any any svc-dhcp permit  (master) (config-sess-guest-control)# user any svc-icmp redirect tunnel 100    
(master) (config-sess-guest-control)# user any svc-dns redirect tunnel 100     

Configure guest ‘pre-logon’ captive portal policy on master controller:      
(master) (config)# ip access-list session captiveportal   
(master) (config-sess-captiveportal)# no user alias mswitch svc-https permit    

The default captive portal policy is configured to allow guest user connections redirected to the VLAN 1 or loopback IP address using https. In this scenario, this behavior is not desirable. The next rule allows connections redirected only to the local Aruba controllers guest VLAN IP address.   

(master) (config-sess-captiveportal)# user alias guestcontrollers svc-https permit position 1   
(master) (config-sess-captiveportal)# user any svc-http dst-nat 8080      
(master) (config-sess-captiveportal)# user any svc-https dst-nat 8081     

Configure the guest ‘pre-logon’ role using the above two policies on master controller:   
(master) (config)# user-role guest-logon   
(master) (config-role)# session-acl guest-control    
(master) (config-role)# session-acl captiveportal  
  

Now that the users are in a locked down state and being forced through the captive portal, we must decide what to do with them after they authenticate. The following set of policies and rules dictate what the guest user is allowed to do after they authenticate.  

Change default ‘cplogout’ policy on master controller:    
(master) (config)# ip access-list session cplogout   
(master) (config-sess-cplogout)# no user alias mswitch svc-https permit    

The default captive portal policy is configured to allow guest user connections redirected to the VLAN 1 or loopback IP address via https. In this scenario, this behavior is not desirable. The next rule allows connections redirected only to the local Aruba controllers guest VLAN IP address.   

(master) (config-sess-cplogout)# user alias guestcontrollers svc-https permit    

Configure guest ‘allowable use’ policy on master controller:    
(master) (config)# ip access-list session guest-internet   
(master) (config-sess-guest-internet)# user alias guestusers any deny
   
blocks a guest user from talking to any other guest user   
(master) (config-sess-guest-internet)# user any svc-http redirect tunnel 100    
(master) (config-sess-guest-internet)# user any svc-https redirect tunnel 100
     

Configure guest ‘post-logon’ role on master controller:     
(master) (config)# user-role guest    
(master) (config-role)# session-acl cplogout    
(master) (config-role)# session-acl guest-control    
(master) (config-role)# session-acl guest-internet
   

We now have two roles configured, a pre authentication role (guest-logon) that forces guest users through the Aruba captive portal, and a post authentication role (guest) that gives authenticated guest users their access rights and restrictions. The next step is to configure how the guest users get into these roles. For the pre authentication role, it is as simple as setting up a rule that forces all users associating to the guest SSID into the ‘guest-logon’ role. For the post authentication piece, we set the default role of any user successfully authenticating against the captive portal (internal database) to the ‘guest’ role.    

Configure SSID derivation of guest role based on guest SSID on master controller:     
(master) (config)# aaa derivation-rules user 
(master) (user-rule)# set role condition essid equals "guestnet" set-value guest-logon
   

Configure Aruba captive portal on master controller:     
(master) (config)# aaa captive-portal auth-server Internal    
(master) (config)# aaa captive-portal default-role guest
 

The last step with regards to the captive portal configuration is to instruct the local Aruba controllers which IP address to redirect the guest users to for the portal page. The way the portal page works is by the ‘captiveportal’ policy intercepting the guest users’ HTTP GET to their home page and sending a HTTP redirect to ‘securelogin.arubanetworks.com’. The guest then issues a DNS request for that name and the controller intercepts it and replies with the controllers IP address, by default the VLAN 1 or loopback IP address. For security reasons this is not desirable, the intent is to have any and all internal address space invisible to the guest user. The following command on the local Aruba controllers instructs it to answer the DNS request for ‘securelogin.arubanetworks.com’ with the configured IP address. Configure alternative captive portal redirect address: 
     
(local) (config)# ip cp-redirect-address 192.168.0.2    
you will use the local controller’s IP address on VLAN 4094    

Configure SSID   
Now that the security (roles and authentication) is in place, the last thing left to do is to configure the guest SSID. Configure guest SSID on master controller:    
(master) (config)# ap location 0.0.0   
(master) (sap-config location 0.0.0 : phy-type a)# phy-type a   
(master) (sap-config location 0.0.0 : phy-type a)# virtual-ap "guestnet" vlan-id 4094 opmode opensystem deny-bcast disable weptxkey 1 hidessid disable dtim-period 1   
(master) (sap-config location 0.0.0 : phy-type a)# phy-type g  (master) (sap-config location 0.0.0 : phy-type g)# virtual-ap "guestnet" vlan-id 4094 opmode opensystem deny-bcast disable weptxkey 1 hidessid disable dtim-period 1   
(master) (sap-config location 0.0.0 : phy-type g)# <ctrl>-Z   
(master)# write memory
   

The last piece needed to test is to add a user to the local database of the master controller:    
(master)# local-userdb add username iamaguest  password thisismypassword role guest     

Scale the Solution 
After all of the configuration steps are complete and a guest access solution is up and running, further local Aruba controllers can be added and a guest service made operational with minimal configuration.   

When adding another local Aruba controller, follow these steps:   
1)     Set up guest VLAN on local controller. 
2)     Set up tunnel to DMZ controller from local controller. 
3)     Add local controller IP address to ‘controllers’ alias on DMZ controller. 
4)     Add local controller guest VLAN IP address to ‘guestcontrollers’ alias on the master controller. 
5)     Configure captive portal redirect address on local controller. 

Comments
Mallikarjun
Can you please share me the topology diagram. Regards, Mallikarjun
Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.