Captive Portal Using Transparent or Redirect Mode in Vwire Deployment

This document is a 'how to' guide in configuring Captive Portal in a Vwire Deployment. It will provide documentation on implementing either Transparent or Redirect mode with Client Certificate Authentication.

Transparent Mode:

Transparent—The firewall intercepts the browser traffic per the Captive Portal rule and impersonates the original destination URL, issuing an HTTP 401 to invoke authentication. However, because the firewall does not have the real certificate for the destination URL, the browser will display a certificate error to users attempting to access a secure site. Therefore you should only use this mode when absolutely necessary, such as in Layer 2 or virtual wire deployment.

Generate the Captive Portal Server Certificate. In this instance, I'm using the Trusted Root CA also used to sign the intermediate/client certificate. You can certainly create a separate Server Certificate if you wish.

Create the authentication profile to utilize. In this case, LDAP is used to authenticate unknown users.

Enable Captive Portal using Transparent Mode. As noted, we are using the previously created LDAP authentication profile and the Captive Portal Server Certificate.

Configure your Captive Portal Policies: (Note, to trigger CP on SSL enabled websites, SSL Decryption will need to be enabled)

After committing your changes, open up a web-browser on the system (the source IP must be an unknown user otherwise you will not get a captive portal prompt) behind the Vwire Trust zone (Note, make sure this zone is enabled for user identification). My host IP is 192.168.125.111 and it's currently unknown on the PA's ip-user-mapping.

As previously mentioned, when using transparent mode, all browsers will issue a warning indicating that the destination url does not match the common name found in the certificate.

After accepting the exception for the common name mismatch, you will be presented with the Captive Portal Web Form requesting for the credentials to authenticate the user.

Upon completing the web form and entering the correct credentials, users will be redirected to the original requested URL/website.

The session table and IP mapping will appear as follows:

Redirect Mode:

Redirect—The firewall intercepts unknown HTTP or HTTPS sessions and redirects them to a Layer 3 interface on the firewall using an HTTP 302 redirect in order to perform authentication. This is the preferred mode because it provides a better end-user experience (no certificate errors). However, it does require additional Layer 3 configuration. Another benefit of the Redirect mode is that it provides for the use of session cookies, which enable the user to continue browsing to authenticated sites without requiring re-mapping each time the time outs expire. This is especially useful for users who roam from one IP address to another (for example, from the corporate LAN to the wireless network) because they will not need to re-authenticate upon IP address change as long as the session stays open. In addition, if you plan to use NTLM authentication, you must use Redirect mode because the browser will only provide credentials to trusted sites.

(To use the captive portal in redirect mode, you must enable response pages on the interface management profile assigned to the Layer 3 interface to which you are redirecting the active portal.)

In this example, I've generated a Trusted Root CA, an intermediate CA which is then signing the client certificate for use in client certificate authentication. For the Trusted CA, which will be used as the Captive Portal Server certificate, I will use 'cpcaroot.pantac2008.com' as the CN and the client cert will have its CN as 'renato.' We will use 'renato' to help identify the users being captive portal'd via the client cert profile.

The 'CA_Root', 'intermediate' certificates are exported in PEM format from the PA and imported into the host client. This can be done more seamlessly in a production environment via GPO. In this scenario, I've imported them to the Trusted Root and Intermediate CA stores respectively.

The client certificate signed by the intermediate cert will need to be exported in PKCS12 format as it will require both the private and public keys to make this work. It will then be imported into your Personal Certificate store accordingly.

The same Captive Portal Policies apply as shown below.

Create the Certificate Profile to utilize for Client Certificate Authentication. Insert both the Trusted Root CA and Intermediate CA within the CA Certificates option. Username Field will be 'Subject' defaulting to common-name. You can modify this option to help identify your users. As mentioned, we'll be using the CN 'renato' to help identify the Captive Portal user by choosing Subject in the Username Field.

Enable the Captive Portal and choose 'Redirect' mode. This will enable other fields that require your attention. I'm using the same Trusted Root CA as the server certificate. The CN used was 'cpcaroot.pantac2008.com. This will be the redirect host configured and we then point to the client cert profile previously created.

In this example, I will have to make sure my host machine knows how to reach 'cpcaroot.pantac2008.com' so I have to configure the host file accordingly. This should not be a problem in a production environment if DNS is able to resolve the fqdn defined as your Redirect Host which should also match the CN for your server certificate.

Windows host file output:

In Vwire deployment while using redirect mode, we'll need to burn an L3 interface on the PA device to get this functional. The interface is assigned to the L3-Trust zone and has a mgmt profile enabled with at the very least, response pages. Notice the IP address used is 192.168.125.2, which is what my system will be redirected to once Captive Portal is triggered given the use of the CN 'cpcaroot.pantac2008.com' in the Captive Portal Server Certificate.

Also, keep in mind that the redirected host will need to be in the same broadcasts domain as the client so that it will respond to arp requests accordingly. If the Captive Portal redirect interface is outside the of the clients broadcast domain and the traffic needs to traverse the v-wire you will need to create an exception policy to allow the traffic destine to this interface a Captive Portal intervention

Here's the screenshot of the host attempting to open a socket to www.google.com. The browser then submits the client cert to the PA device as we're using client certificate authentication instead of LDAP in this scenario. I subsequently redirect the browser to www.jimmyr.com and I'm now presented the web page and CP has identified me as 'renato' per my client certificate.

Previously seen as unknown for 192.168.125.223:

Upon completing the client certificate authentication, the PA now reflects the following:

Here's an example of client certificate authentication using an Ubuntu client with Firefox as the browser. I've installed the Root CA and intermediate certificate in the Trusted store for Firefox whereas the client certificate is associated with 'Your Certificates' store.

Here's Firefox presenting the client certificate upon the user's attempt to access www.jimmyr.com

Finally, the original requested website is presented to the user

PA CLI output fo the syslog and ip-user-mapping below:

The following is an example from a MacOS client using the Chrome browser. We've copied the same certs using the Keychain Access Certificates and My Certificates folder respectively.

As you can see once again, PA is requesting client certificate authentication and Chrome is presenting said client certificate as expected.

1. 192.168.125.113 vsys1 Unknown unknown 3 6

1. 192.168.125.113 vsys1 CP renato 899 3585