Aruba Networks – Configuring Captive Portal for Guest Access on RAP

Captive Portal is used frequently in a campus AP environment to provide wireless access for guest users.  The same functionality can be extended to the Virtual Branch Networks (VBN) environment. Typically, a wireless SSID (virtual AP) used for guest access in a Remote AP (RAP) is configured in ‘bridge’ mode (traffic routed locally).  However, the Aruba captive portal is hosted on the controller only. Therefore, an user associated to an SSID in bridge mode (forwarding mode) will not be able to reach the captive portal pages hosted on the controller.  In order to get around this, the SSID must be set-up in ‘split-tunnel’ mode. 

 
This article describes how a guest captive portal can be set-up on a RAP at the same time not compromising security of corporate-bound traffic.
 
Details
 
Below please find the detailed configuration steps (using CLI) for setting up a captive portal for a guest SSID on a RAP.  This set-up has the following characteristics:
 
1) The Guest SSID does not employ any wireless encryption (open system).  Changing this to use pre-shared key is trivial and will be left to the readers.
 
2) Guests users are placed in a private VLAN which is isolated from normal corporate users.  Private IP addresses are assigned by a DHCP server on the controller.
 
3) The Captive Portal is hosted on the controller where the RAP is terminated.  It can be further customized (please refer to ArubaOS User Guide for details).  Authentication of captive portal users are by the userid and password stored in the Internal DB.
 
4) Prior to authentication (with Captive Portal), guest users are placed in a quarantined role with access only to the captive portal on the controller.
 
5) After authentication, users are placed in a role where all traffic are routed locally out to the Internet from the up-link port of the RAP, with exception to make provision for the user to log-out.  All traffic is sourced-NATted to the IP address of the uplink port of the RAP.  This ACL can be further customized to limit traffic to a small subset of allowed protocols (e.g. dns, http and https only).
 
 
Configuration Steps
 
[Note that the IP addresses in the following config example are specific to a test set-up. ]
 
Configure an alias containing the IP addresses of the DNS servers at corporate.  For captive portal to function properly, DNS servers must be used initially.  However, a local DNS server can be used (with the Split DNS feature) post-authentication.
 
netdestination corp-dns-servers                   
  host 10.1.1.50                                  
  host 10.1.1.200        
 
Set-up a private VLAN and IP address.  In order for a user to reach the DNS user, src-nat must be set-up
 
vlan 21      
interface vlan 21                                 
        ip address 192.168.199.1 255.255.255.0    
        ip nat inside               
 
Set-up two ACL’s and the initial role (pre-authentication) of the guest user.  These ACL’s will only allow essential traffic to get through to the controller.  Also, a captive portal profile is configured for this initial role.
 
ip access-list session vbn-guest-control          
  user any udp 68 deny                            
  any any svc-dhcp permit                         
  any any svc-dns permit                          
  any any svc-icmp permit      
 
ip access-list session vbn-guest-captiveportal    
  user   alias controller svc-https dst-nat 8081  
  user any svc-http dst-nat 8080 log              
  user any svc-https dst-nat 8081         
 
aaa authentication captive-portal “vbn-guest”
   default-role “vbn-guest”
 
user-role vbn-guest-logon                         
 captive-portal vbn-guest                         
 session-acl vbn-guest-control                    
 session-acl vbn-guest-captiveportal     
 
 
Set-up the ACL for the authenticated guest user.  Note that this role would src-nat all traffic locally with the exception to allow user to ‘logout’
 
ip access-list session vbn-guest                  
 any any svc-dhcp permit                         
 user   alias corp-dns-servers svc-dns permit    
 user   alias controller svc-https dst-nat 8081  
 user any any route src-nat                   
 
user-role vbn-guest                               
 session-acl vbn-guest   
 
Tying them all together with the necessary AAA, Virtual-AP, and SSID profiles. 
 
aaa profile “vbn-guest”                           
   initial-role “vbn-guest-logon”      
 
wlan ssid-profile “vbn-guest”
   essid “Guest”
 
wlan virtual-ap “vbn-guest”
   ssid-profile “vbn-guest”
   vlan 21
   forward-mode split-tunnel
   aaa-profile “vbn-guest”    
 
 
Enable the ‘Split-DNS’ function.  Only domain names matching ‘arubanetworks.com’ would be sent to the DNS servers at corporate. All other DNS queries would go to the local DNS servers.  Please ensure that this matches the CN name of the SSL certificate on the Aruba controller.
 
ap system-profile <AP-System-Profile>
  dns-domain “arubanetworks.com”
 
Adding this Virtual AP to any AP group where this SSID is needed.
 
ap-group <AP-Group>
   virtual-ap <other VAP>
   virtual-ap “vbn-guest”
   ap-system-profile <AP-System-Profile>
 
 
Operation
 
- When a user associate to this Guest SSID, would be placed in the ‘vbn-guest-logon’ role where all HTTP/HTTPS traffic is re-directed to the captive portal on the controller via the IPSec tunnel between the RAP and the controller.
 
- Users authenticates using the Internal DB.
 
- Users authenticated successfully would be placed in the ‘vbn-guest’ role were most traffic are routed (src-nat) locally.
 
- Users will idle-out normally or can log-out manually using the standard logout button.