Configuring Captive Portal in V-Wire (with RADIUS Authentication)
Environment
Overview
The Captive Portal is used to create a user-to-IP mappings on the Palo Alto Networks firewall. The portal is triggered based on the Captive Portal policies for http and/or https traffic only and is triggered only for the IP addresses without existing user-to-IP mapping. For user authentication, a local database can be used, RADIUS, Kerberos, or LDAP server. Once identified, user-based policies can be applied to the user’s traffic. While captive portal is most commonly used in a Layer 3 routed environment, this document outlines the steps to configure a V-Wire topology with Captive Portal in redirect mode authenticating to a RADIUS server.
Prerequisites
As illustrated above, the network topology for this configuration requires two physical interfaces configured for the inbound and outbound V-Wire. A third physical interface should be configured with an IP and assigned to a zone outside the V-Wire. This L3 interface will be used for the Captive Portal redirect. The firewall will intercept any unknown user sessions that are using HTTP or HTTPS with an HTTP 302 redirect message. The redirection is configured to a specified host name that will be resolved to IP address assigned to L3 interface. Decryption needs to be enabled in order for the firewall to send a redirect message for https traffic. The captive portal should present a certificate and should be trusted by the end users (CA issuing the certificate should be present in Trusted Root store on the client machine). The users will not receive any certificate warning for https redirection. Also, the firewall will set a cookie in the client browser therefore the end user does not need to re-type username/password while cookie is valid (expiry timer can be set in captive portal configuration).
A DNS entry should be made for the IP address configured on the L3 interface. The DNS host name will be used as the Common Name when creating the Captive Portal authentication certificate and can be used in the configuration for the Captive Portal redirect. A RADIUS server with user accounts already defined must be running in the network and configured to operate on ports 1812 or 1645.
Information on configuring RADIUS can be found here: How to Configure Radius on Windows 2008 Server
RADIUS authentication is sent from the firewall management interface to the RADIUS server. If this RADIUS traffic passes through the firewall data ports (Data Plane), a security rule should be created (if not existing already) permitting this traffic.
If there is no existing policy denying intra-zone traffic, a security policy will not be required to allow the traffic from L3 interface used by Captive Portal.
Resolution
Part 1: Configure Captive Portal, Authentication, and Policies
Configure the RADIUS Server Profile
- Go to the "Device tab > Server Profiles > RADIUS" and create the RADIUS server profile. Fill in the profile Name, server Name, IP Address, Port (1812 or 1645) and Secret.
Configure the Authentication Profile
- Go to the "Device tab > Authentication Profile" and Add a new profile
- Fill in a Profile Name, and add the Users which should be able to authenticate against the RADIUS server in the allow list
- Choose Authentication RADIUS from the drop-down menu (options are None, Local DB, RADIUS, LDAP or Kerberos)
- Choose the server profile that was just created for the RADIUS server.
Generate a Self-Signed Certificate or Import an Existing Certificate to the Firewall
- Go to the "Device tab > Certificate Management > Certificates"
- Option 1: Generate a self-signed certificate; Use the FQDN, which will be mapped in DNS to the L3 interface hosting the captive portal, as the Common Name for the certificate; Other fields are not mandatory.
- Option 2: The generated CSR (Certificate Signing Request) will be exported and signed by external authority and then imported back to the firewall (use the same Common Name as for Option 1)
- Option 3: Import both the certificate and the private key, which were create by the external CA.
Configure Captive Portal
- Go to the "Device tab > User Identification > Captive Portal Settings"
- Edit the Captive Portal settings
- Check the box to enable captive portal
- Select the previously created or imported Captive Portal certificate for the Server Certificate
- Select the previously configured Authentication Profile
- Enable Redirect mode
- For the Redirect host, type the FQDN which will be translated to interface L3 IP address; The host name must match the Common Name used on the Captive Portal certificate
- Idle Timer: The amount of time needed to clear captive portal session (mapping) if the authenticated user is inactive
- Expiration: The maximum time the captive portal session can be active for a single user; after this the mapping will be removed and the user will have to re-authenticate
- Session cookie timeout is the time session cookie is valid; if the user's browser presents the cookie to the captive portal they do not need to enter credentials again
- Roaming options allow for the same cookie to be used when the client is roaming (changing the IP address)
Note: In Transparent mode, the firewall is impersonating the destination http/https website and sending http 401 message to invoke authentication. Since the firewall does not have a certificate for the actual destination the user will always receive a certificate warning. Using the Redirect mode is generally recommended.
Configure the Interface Management Profile and Assign it to the Interface:
- Go to the "Network tab > Network Profiles > Interface Mgmt"
- Management Profile assigned to the L3 interface needs to have “Response Pages” enabled:
- Go to the "Network tab > Interfaces" and select the appropriate L3 interface to apply the Interface Management Profile:
Configure Captive Portal Policies:
Go to the "Policies tab > Captive Portal" rule base. In this example, authenticating users is coming from the trust zone (make sure the trust zone has the User-ID checkbox enabled) and going to the untrust zone (internet). For the initial test, limit this rule to a single IP or a group of users. Users (IPs) not matching the CP policy can not trigger the CP redirection. Do not configure the redirection for https service if decryption is not enabled. The configured action is "web-form", meaning the user will be redirected to the captive portal page if there is no mapping for its IP address:
Configure and Adjust the Security Rules Based on the Particular Scenario
- Go to the "Policies tab > Security" rule base
- Make sure that captive portal traffic is allowed by security policies; we need to ensure that the users being redirected can reach the L3 interface serving the portal page; http redirection is used with port 80, while https redirection is using ports 6080/6081/6082/6083.
- Make certain the DNS traffic is allowed for the users (in order for redirection to work, user must first try to access external web site)
- Often, there is no need to create any additional security policies if the intra-zone traffic is enabled. Users from the trust zone will be able to reach the captive portal in the trust zone
Part 2: Test the Captive Portal
- Confirm that the captive policy rule will be triggered for a particular user using "test cp-policy-match" CLI command; also, check if there is not user-to-IP mapping for the user's IP address
> test cp-policy-match source <source_ip> from trust to untrust destination <destination_ip>
> show user ip-user-mapping ip <ip_address>
> show user ip-user-mapping-mp ip <ip_address>
- When loading external http/https web sites it should be redirected to the Captive Portal page for authentication. The Captive Portal page can be customized (Device tab > Response Pages).
- Once the appropriate credentials are entered (checked by the RADIUS server), it will load the initially requested page. The firewall will create user-to-IP mapping (source of the mapping will be marked as CP):
> show user ip-user-mapping-mp all
IP Vsys From User Timeout (sec)
--------------- ------ ------- -------------------------------- ----------------
172.16.21.93 vsys1 CP paloaltonetworks\user1 895 <<< user mapped by Captive Portal
172.16.32.1 vsys1 GP pre-logon 2588475
192.168.21.94 vsys1 AD paloaltonetworks\user2 6
Total: 3 users
*: WMI probe succeeded
- If the user has the mapping on the firewall, it can be cleared for testing purposes and can also clear the captive portal session for a user with the following CLI commands:
> clear user-cache ip <ip_address>
> clear user-cache-mp ip <ip_address>
> debug device-server reset captive-portal ip-address