Guest Networks with Captive Portal Authentication

Guest Networks with Captive Portal Authentication

Guest networks are often defined by what the guest is not allowed to do and where they are not allowed to go. These are the most common guest usage requirements in enterprises deployments:

●Guest users must be separated from employee users.
●Guests must be limited by:
■What resources they can access
■What protocols they are allowed to use
■What time of the day they can access the network
■The amount of bandwidth or air time they can use
●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. Aruba recommends the use of a public DNS server for guest networks.
●All other internal resources should be unavailable for the guest.
●Employee traffic should be prioritized on the wireless medium.

The native ArubaOS can be configured to address these requirements of an enterprise network.



Captive Portal

Wireless networks used by corporate employees should always be secured using Layer 2 methods such as WPA2. For guest access, providing Layer 2 authentication using pre-shared keys (PSK) or 802.1X is not a viable solution due to the technical complexity. Instead authentication is moved to Layer 3. Captive portal authentication is a Layer 3 authentication method that redirects users to a captive portal page when they start a web session. The captive portal page can be used for various purposes, such as authenticating the guest using a user name and password, providing an acceptable use policy, or self registration with an email address.
Captive portal on ArubaOS can be configured to authenticate guest users based on user/password or valid email ID information. The system can also be configured simply to present an acceptable use policy and an accept button through custom configuration of the HTML page. ArubaOS does not support the use of advanced features such as payment services, but it can redirect to other portals such as Amigopod for additional services.


Captive Portal Authentication Process

Captive portal is a Layer 3 authentication, which requires that the devices connect to the network and obtain an IP address and related DNS information before authenticating through the captive portal. The following steps explain the entire captive portal process when the native ArubaOS is used for captive portal authentication:

1.The device that is associating to the guest SSID is assigned an initial role (guest-logon role in the example configuration). This initial role allows DHCP, so the user gets an IP address.
2.The user opens a browser and makes an HTTP (or HTTPS) request to some destination (for example, www.bbc.com).
3.The resolver in the device sends a DNS request to resolve the www.bbc.com. The initial role (guest-logon role) permits DNS services, so the resolver can communicate with the DNS server.
4.The DNS server replies with the correct address to www.bbc.com.
5.The resolver tells the browser which IP address to use based on the DNS reply.
6.The browser initiates a TCP connection to port 80 of the www.bbc.com address.
7.The controller intercepts the connection and spoofs the initial TCP handshakes of the HTTP process. At this moment, the client browser thinks it is communicating with the bbc.com server.
8.When the browser sends the HTTP GET request for the web page, the controller replies saying that bbc.com has “temporarily moved” to <https://securelogin.arubanetworks.com/[string that identifies client]>.
9.The browser closes the connection.
10.The browser attempts to connect with <https://securelogin.arubanetworks.com/[string that identifies client]>, but it first needs to send a DNS request for the address.
11.The actual DNS server responds that it cannot resolve
<https://securelogin.arubanetworks.com>, but the controller intercepts that reply and changes the packet to say that securelogin.arubanetworks.com is at the IP address of the controller itself. Remember that it is critical that the DNS server sends back a reply to the query.  It is only then that the controller can spoof the reply back from the DNS server.  Sending a DNS request without receiving a reply is not sufficient, since without a reply the controller will never help the client resolve securelogin.arubanetworks.com.
12.The browser initiates an HTTPS connection to address of controller, which responds with the captive portal login page, where the guest authenticates.
13.After successful authentication, the user is assigned the post authentication role (auth-guest role in the example configuration). This is the default role in the captive portal profile.
14.After authentication, the browser is redirected to bbc.com at the address originally resolved by the DNS. Alternatively, if a welcome page is configured, the browser is redirected to the welcome page.
15.To successfully redirect to the original web page the controller spoofs a reply from bbc.com to tell the client that bbc.com has “permanently moved” to bbc.com. This step corrects the “temporary relocation” that occurred as part of the captive portal login.
16.This causes the client to re-query DNS for the address of www.bbc.com.
17.The browser starts to communicate with the actual bbc.com server.

*****************
this is an EXAMPLE of a - Captive Portal Authentication
*****************