Chapter 4: Captive Portal Configuration

Chapter 4: Captive Portal Configuration
A number of tasks are necessary to configure a fully functional guest WLAN. Some of this work is simplified through the use of the configuration wizards, and Aruba highly recommends that you use the wizard where possible. The following list outlines the tasks necessary to configure captive portal authentication:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Guest VLAN and Related DHCP Services
The guest users must be isolated to a subnet that is hidden from the corporate network. Defining a VLAN (subnet) that is local to the controller restricts the guests to a subnet that is not routable in the core network. This VLAN adds an additional layer of security to the design by hiding the IP addressing scheme used in the core network from guests and users who accidentally associate with the guest WLAN.
The guest VLAN is local to the controller, so it is essential to source-NAT this VLAN and define the required DHCP and DNS services. The controller should be the DHCP server for the guest VLAN and this VLAN should be source-NATed by the IP address of the controller to which the VLAN belongs. Source-NATing allows the guest users to reach the allowed destinations while they are still isolated from the core network.
The VLAN and DHCP services required for the guest network should be configured on the controller that terminates the APs. In a master/local deployment, this is usually the local controller.
Table 3 and Table 4 and Figure 1 through Figure 5 show the configuration of a guest VLAN and the related DHCP services.
Table 3 Guest VLAN
Guest VLAN Configuration
!
interface vlan 900
interface vlan 900 ip address 192.168.200.1 255.255.255.0
!
 
Figure 1 Creating a VLAN
Figure 2 Configuring IP parameters for the guest VLAN
Figure 3 Guest VLAN
Source-NAT Configuration for the Guest VLAN
!
interface vlan 900
ip nat inside
!
 
Figure 4 Source-NATing the guest VLAN
 
Test that the DNS services are working properly from the guest subnet. A functional DNS service is an integral part of captive portal authentication process.
DHCP Server Configuration for the Guest VLAN
!
ip dhcp pool "guestpool"
default-router 192.168.200.1
dns-server 208.67.222.222 208.67.222.220
network 192.168.200.0 255.255.255.0
!
service dhcp
!
 
Figure 5 Configuring the DHCP pool
Figure 6 Enabling the DHCP server
Use the public DNS server in your location. If a public DNS server is not available in your region, the guest users should be allowed access to the internal DNS server.
Guest User Roles
In the Aruba user-centric network, every client is associated with a user role. The user roles that are enforced through the firewall policies determine the network privileges of a user. A policy is a set of rules that applies to the traffic that passes through the Aruba devices. The rules and policies are processed in a top-down fashion, so the position of a rule within a policy and the position of a policy within a role determine the functionality of the user role. When you construct a role, you must put the rules and policies in the proper order.
Usually, guests are assigned two different roles. The first role is assigned when they associate to the guest SSID, and the other is assigned when they authenticate successfully through the captive portal. Only the guests who successfully authenticate are allowed to use to the services needed to connect to the Internet.
Consider the guest-logon role as the initial role and the auth-guest role for authenticated guests. Before these two roles are configured, the policies that are associated with them must be configured.
The guest-logon role uses these policies:
The auth-guest role uses these policies:
A policy might have one or more rules that apply to several networks or hosts. Creating a separate rule for each host or network might be laborious and will increase the number of rules in the policy. The network destination alias feature in the ArubOS can be used to simplify firewall polices that have a set of rules that are common to a group of hosts, domains, or networks.
Network Destination Alias
The network destination alias feature in the ArubaOS can be used to group several hosts or networks. Aliases can be used when several rules have protocols and actions common to multiple hosts or networks. Alias allows the addition of domain/host names and IP addresses. The IP addresses can be added by host, network, or range. When the invert parameter of an alias is enabled, the rules that use that alias are applied to all the IP addresses, domains and hostnames except those specified in the alias.
Table 5 lists the aliases that will be useful in configuration of user roles.
Table 5 Aliases
Network Destination Alias Configuration
!
netdestination Internal-Network
network 10.0.0.0 255.0.0.0
network 172.16.0.0 255.240.0.0
network 192.168.0.0 255.255.255.0
!
netdestination Public-DNS
host 208.67.222.222
host 208.67.222.220
!
 
Figure 7 Aliases
Defining Guest Access Policies
Guest roles are made up of a number of polices that can be predefined and reused in the system. The following sections describe the policies that will be used to define the rights of the guest in their various roles.
Configuring the guest-logon-access Policy
The guest-logon-access policy is similar to predefined logon-control policy, but it is much more restrictive. The guest-logon-access policy is a part of the guest-logon and auth-guest roles. The rules defined in this policy allow these exchanges:
Remember that the guests should be allowed to access only the local resources that are required for IP connectivity. These resources include DHCP and possibly DNS if an outside DNS server is not available.
Table 6 summarizes the rules used by the guest-logon-access policy.
Rule Number
This rule drops responses from a personal DHCP server. This action prevents the clients from acting as DHCP servers.
This rule allows clients to request and discover DHCP IP addresses over the network. The DHCP server on the network does not fall under the user category. Therefore, its response on port 68 is not dropped by the first rule. The first two rules guarantee that DHCP is processed only by legitimate DHCP servers on the network.
This rule allows DNS queries only to the DNS servers that are defined in the Public-DNS alias.
guest-logon-access Policy Configuration
!
ip access-list session guest-logon-access
user any udp 68 deny position 1
any any svc-dhcp permit position 2
user alias Public-DNS svc-dns permit position 3
!
 
Figure 8 guest-logon-access policy
Configuring the block-internal-access Policy
The internal resources of an organization should be available only to employees or to trusted groups. Guest users are not part of the trusted entity, so they must be denied access to all internal resources. As the name implies, the block-internal-access policy denies access to all internal resources. This policy is a part of the guest-logon and auth-guest roles.
Table 7 summarizes the rules used by the block-internal-access policy.
Rule Number
This rule denies access to all the addresses that are in the Internal- Network alias.
block-internal-access Policy Configuration
!
ip access-list session block-internal-access
user alias Internal-Network any deny position 1
!
 
Figure 9 block-internal-access policy
Configuring the auth-guest-access Policy
The most important purpose of the auth-guest-access policy is to define the protocols and ports that the users are allowed to access. This policy is an integral part of the auth-guest role. The auth-guest-access policy allows HTTP and HTTPS traffic to go to any destination from the user. When this policy is combined with the block-internal-access policy in the auth-guest role, the users will be allowed HTTP and HTTPS access to the public websites only.
If you want your guest users to use their IPsec clients, create rules in this policy that allows the use of ports 4500 (for IPsec NAT-T) and 500 (for IKE).
Table 8 summarizes the rules used by the auth-guest-access policy.
Rule Number
auth-guest-access Policy Configuration
!
ip access-list session auth-guest-access
user any svc-http permit position 1
user any svc-https permit position 2
!
 
Figure 10 auth-guest-access policy
Configuring the drop-and-log Policy
The drop-and-log policy denies all traffic and records the network access attempt.
The logging function in this policy increases your syslog repository. If you do not require logging, remove the log action from the firewall rule of this policy.
Table 9 summarizes the rule used by the drop-and-log policy.
Rule Number
This rule denies access to all services on the network and logs the network access attempt.
drop-and-log Policy Configuration
!
ip access-list session drop-and-log
user any any deny log position 1
!
 
Figure 11 drop-and-log policy
Configuring the guest-logon Role
The guest-logon role is the first role that is assigned to the users when they associate with the guest SSID. Users in this role have access only to the DHCP/DNS services and are redirected to the captive portal page whenever they try to access a web page. The captive portal page requires login credentials. The captive portal authentication profile that is appended to this role specifies the captive portal login page and other configurable parameters such as the default role and the type of login. To create and add the captive portal authentication profile to this guest role, see Configuring the Captive Portal Authentication Profile . Table 10 describes the policies in the guest-logon role.
Policy Number
This predefined policy initiates captive portal authentication. This policy redirects any HTTP or HTTPS traffic to port 8080, 8081, or 8088 of the controller. When the controller sees traffic on these ports, it checks the captive portal authentication profile associated with the current role of the user and processes the values specified on this profile.
guest-logon Role Configuration
!
user-role guest-logon
access-list session captiveportal position 1
access-list session guest-logon-access position 2
!
 
Figure 12 guest-logon role
Configuring the auth-guest Role
The auth-guest role is assigned to users after they authenticate successfully through the captive portal. This role is the default role in the captive portal authentication profile. This role allows only HTTP and HTTPS services to Internet.
Sometimes an organization wants its guest users to use the printers in the internal network. In such cases, create a separate policy that allows user traffic to an alias called printers. This alias must include only the IP address of the printers that the guests are allowed to use. Place this policy in the auth-guest user role just above the block-internal-access policy.
Table 11 describes the policies in the auth-guest role.
Policy Number
This policy makes the controller present the captive portal logout window. If the user attempts to connect to the controller on the standard HTTPS port (443), the client is NATed to port 8081, where the captive portal server will answer. If this rule is not present, a wireless client may be able to access the administrative interface of the controller.
This policy blocks access to internal network. This policy should be placed before the next policy that allows HTTP and HTTPS service, otherwise guest users will have access to the internal websites.
Any traffic that does not match the previous policies encounters this policy. This policy denies all services and logs the network access attempt.
auth-guest Role Configuration
!
user-role auth-guest
access-list session cplogout position 1
access-list session guest-logon-access position 2
access-list session block-internal-access position 3
access-list session auth-guest-access position 4
access-list session drop-and-log position 5
!
 
Figure 13 auth-guest
Configuring the SSID Profile for Guest WLAN
As previously mentioned, guest SSIDs typically do not provide any Layer 2 authentication and encryption. The Layer 2 authentication type used is open. In open authentication, hello messages are exchanged with the client before it is allowed to associate and obtain necessary IP information. All the user traffic is unencrypted. The users that associate to this SSID are placed in the guest VLAN. This WLAN uses captive portal to authenticate the users. Captive portal with open Layer 2 authentication should never be used for employee networks, because captive portal does not provide encryption. The wireless traffic is visible to anyone doing a passive packet capture unless the data is encrypted by higher-layer protocols such as HTTPS and IPsec.
If you require encryption of data for guest users, other Layer 2 authentication types such as WPA2-PSK can be used before the users are redirected to the captive portal. However, this approach requires that credentials such as the pre-shared key are distributed to all guest users.
Table 12 summarizes the parameter in the sample guest SSID profile.
Network Name (SSID)
Guest users. (Captive portal is used to provide Layer 3 authentication.)
Guest SSID Profile Configuration
!
wlan ssid-profile "guestnet"
essid "Guest"
opmode opensystem
!
 
Figure 14 Guest SSID profile configuration
Configuring the Internal Database for Guest Authentication
The user credentials provided by the captive portal users must be authenticated against an authentication server. Any server type available in ArubaOS can be used as an authentication server, including the internal database. If the guest provisioning feature of ArubaOS is required, the internal database must be used as the authentication server.
Create a server group that defines the internal database of the controller as the authentication server. By default, the credentials entered on the captive portal page by the guests are validated against the user credentials in the database of the master controller. So, in a master/local operation all the guest user accounts are created in the internal database of the master controller. For details about using the internal database of the local controllers for guest accounts in master/local deployments, see Chapter 5: Guest Provisioning.
Table 13 lists the parameter in the Guest-internal server group.
Table 13  
Server Group Configuration
!
aaa server-group "Guest-internal"
auth-server Internal
!
 
Figure 15 Server group
Configuring the Captive Portal Authentication Profile
As discussed earlier, to authenticate the users who are associated with the guest SSID via captive portal, you must define and attach a captive portal profile to the initial role that is assigned to the guest users. Configurable parameters such as the default role, type of login (user or guest), welcome page, and others are available in a captive portal profile. The default captive portal page in the ArubaOS is customizable.
Table 14 summarizes the most important parameters of the captive portal profile and the configuration used in the example.
Sample Configuration (guestnet captive portal profile)
A username and password is necessary to pass captive portal authentication when user login is enabled. Users authenticating through user login are assigned the role specified in the default role field of the captive portal profile.
This role is assigned to users after successful authentication through user login.
The captive portal does not request any credentials and the users can login by providing a valid email address. Users authenticating through guest login are assigned the role specified in the default guest role field of the captive portal profile. When user login and guest login is enabled, users can login using either credentials or valid email address.
This role is assigned to users after successful authentication through guest login.
Presents a logout window after the user is authenticated. If this is disabled, the user will be logged in until the user age-out is reached or until the client device is rebooted. Pop-up blockers in the browsers may block this pop-up.
This is the captive portal page that is displayed to the users. This can be the default page, the new customized page, or any external captive portal page such as the one hosted on Amigopod.
This enables the welcome page. If disabled, the authenticated user is redirected automatically to the page he was trying to browse initially.
If enabled, it displays the acceptable use policy during captive portal authentication. For detail, see Walled Garden.
Remember to add a server group, which defines internal database as the authentication server, to the captive portal profile.
Captive Portal Configuration
!
aaa authentication captive-portal "guestnet"
default-role "auth-guest"
no guest-logon
server-group "Guest-internal"
logout-popup-window
login-page "/auth/index.html"
welcome-page "/auth/welcome.html"
show-acceptable-use-policy
!
 
Figure 16 Captive portal profile (using the sample configuration in Table 14)
Figure 17 Captive portal page when user and guest login are enabled
Figure 18 Captive portal page for user login
Figure 19 Captive portal page for guest login
After you configure the captive portal profile, append it to the initial role, which is the guest-logon role in the example configuration.
Appending Captive Portal Profile to Initial Guest Role
!
user-role guest-logon
captive-portal guestnet
!
 
Figure 20 Appending the captive portal profile to the initial guest role
Configuring the AAA Profile for Guest WLAN
The AAA profile defines the user role assigned to authenticated and unauthenticated users. Since the guest SSID is open, any user associating is given the user role specified as the initial role in the AAA profile. The initial guest role should be the initial role in the AAA profile. In the example configuration this is the guest-logon role.
Table 15 lists the initial role of the guest AAA profile.
Guest AAA Profile Configuration
!
aaa profile "guestnet"
initial-role "guest-logon"
!
 
Figure 21 Guest AAA profile configuration
After completing all the above configurations, create the required VAP profile and attach it to an AP group. For details about configuring the VAP profiles and AP groups, see the Aruba Campus Wireless Networks Validated Reference Design.