Captive Portal Using Transparent or Redirect Mode in Vwire Deployment
Resolution
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.
admin@lab-26-PA5050> show user ip-user-mapping all
admin@lab-26-PA5050>
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:
admin@lab-26-PA5050> show user ip-user-mapping all
IP Vsys From User IdleTimeout(s) MaxTimeout(s)
--------------- ------ ------- -------------------------------- -------------- -------------
192.168.125.111 vsys1 CP rkalugdan 888 3462
Total: 1 users
admin@lab-26-PA5050> show session id 33570653
Session 33570653
c2s flow:
source: 192.168.125.111 [vtrust]
dst: 209.95.138.162
proto: 6
sport: 39066 dport: 80
state: ACTIVE type: FLOW
src user: rkalugdan <==================================== via Captive Portal
dst user: unknown
s2c flow:
source: 209.95.138.162 [vuntrust]
dst: 192.168.125.111
proto: 6
sport: 80 dport: 39066
state: ACTIVE type: FLOW
src user: unknown
dst user: rkalugdan
DP : 1
index(local): : 16221
start time : Tue Jan 27 08:27:52 2015
timeout : 3600 sec
time to live : 3593 sec
total byte count(c2s) : 1381
total byte count(s2c) : 1006
layer7 packet count(c2s) : 13
layer7 packet count(s2c) : 12
vsys : vsys1
application : web-browsing
rule : vwire
session to be logged at end : True
session in session ager : True
session updated by HA peer : False
layer7 processing : enabled
URL filtering enabled : True
URL category : content-delivery-networks
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : ethernet1/6
egress interface : ethernet1/4
session QoS rule : N/A (class 4)
end-reason : unknown
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:
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#
192.168.125.2 cpcaroot.pantac2008.com
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:
admin@lab-26-PA5050> show user ip-user-mapping all
IP Vsys From User IdleTimeout(s) MaxTimeout(s)
--------------- ------ ------- -------------------------------- -------------- -------------
192.168.125.223 vsys1 Unknown unknown 2 5
Total: 1 users
Upon completing the client certificate authentication, the PA now reflects the following:
admin@lab-26-PA5050> show log system direction equal backward
2015/01/27 09:05:58 info general general 0 User admin logged in via CLI from 192.168.125.223
2015/01/27 09:05:58 info general auth-su 0 User 'admin' authenticated. From: 192.168.125.223.
2015/01/27 09:05:40 info general general 0 Captive Portal authentication succeeded for user: renato on 192.168.125.223, vsys1
2015/01/27 09:05:40 info general general 0 Captive Portal client certificate authentication successful from ::ffff:192.168.125.223.
admin@lab-26-PA5050> show user ip-user-mapping all
IP Vsys From User IdleTimeout(s) MaxTimeout(s)
--------------- ------ ------- -------------------------------- -------------- -------------
192.168.125.223 vsys1 CP renato 899 3518
192.168.125.111 vsys1 CP rkalugdan 261 1037
Total: 2 users
admin@lab-26-PA5050> show session id 33571113
Session 33571113
c2s flow:
source: 192.168.125.223 [vtrust]
dst: 216.58.216.2
proto: 6
sport: 51049 dport: 80
state: ACTIVE type: FLOW
src user: renato <======================================================
dst user: unknown
s2c flow:
source: 216.58.216.2 [vuntrust]
dst: 192.168.125.223
proto: 6
sport: 80 dport: 51049
state: ACTIVE type: FLOW
src user: unknown
dst user: renato
DP : 1
index(local): : 16681
start time : Tue Jan 27 09:05:41 2015
timeout : 3600 sec
time to live : 3580 sec
total byte count(c2s) : 3637
total byte count(s2c) : 9854
layer7 packet count(c2s) : 10
layer7 packet count(s2c) : 14
vsys : vsys1
application : web-browsing
rule : vwire
session to be logged at end : True
session in session ager : True
session updated by HA peer : False
layer7 processing : enabled
URL filtering enabled : True
URL category : web-advertisements
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : ethernet1/6
egress interface : ethernet1/4
session QoS rule : N/A (class 4)
end-reason : unknown
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:
admin@lab-26-PA5050> show user ip-user-mapping all
IP Vsys From User IdleTimeout(s)
MaxTimeout(s)
--------------- ------ ------- -------------------------------- --------------
-------------
192.168.125.111 vsys1 CP renato 893
3561
Total: 1 users
dmin@lab-26-PA5050> show log system direction equal backward
Time Severity Subtype Object EventID ID Description
===============================================================================
2015/01/27 13:24:07 info general general 0 Accepted keyboard-interactive/pam for admin fr
om 192.168.125.111 port 50672 ssh2
2015/01/27 13:23:45 info general general 0 User admin logged in via CLI from 192.168.125.1
11
2015/01/27 13:23:44 info general auth-su 0 User 'admin' authenticated. From: 192.168.125
.111.
2015/01/27 13:23:11 info general general 0 Captive Portal authentication succeeded for use
r: renato on 192.168.125.111, vsys1
2015/01/27 13:23:11 info general general 0 Captive Portal client certificate authenticatio
n successful from ::ffff:192.168.125.111.
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.
admin@lab-26-PA5050> show user ip-user-mapping all
IP Vsys From User IdleTimeout(s) MaxTimeout(s)
--------------- ------ ------- -------------------------------- -------------- -------------
- 192.168.125.113 vsys1 Unknown unknown 3 6
Total: 1 users
admin@lab-26-PA5050> show user ip-user-mapping all
IP Vsys From User IdleTimeout(s) MaxTimeout(s)
--------------- ------ ------- -------------------------------- -------------- -------------
- 192.168.125.113 vsys1 CP renato 899 3585
Total: 1 users
Time Severity Subtype Object EventID ID Description
===============================================================================
2015/01/27 13:00:40 info general general 0 WildFire update job succeeded for user Auto update agent
2015/01/27 13:00:39 info general general 0 Wildfire package upgraded from version <unknown version> to 51969-58674 by Auto update agent
2015/01/27 13:00:37 info general general 0 Installed wildfire package: panup-all-wildfire-51969-58674.tgz
2015/01/27 13:00:35 info general general 0 WildFire version 51969-58674 downloaded by Auto update agent
2015/01/27 13:00:34 info general general 0 Connection to Update server: completed successfully, initiated by 10.46.32.26
2015/01/27 13:00:23 info general general 0 Connection to Update server: updates.paloaltonetworks.com completed successfully, initiated by 10.46.32.26
2015/01/27 13:00:21 info general general 0 Connection to Update server: updates.paloaltonetworks.com completed successfully, initiated by 10.46.32.26
2015/01/27 13:00:20 info general general 0 Captive Portal authentication succeeded for user: renato on 192.168.125.113, vsys1
2015/01/27 13:00:20 info general general 0 Captive Portal client certificate authentication successful from ::ffff:192.168.125.113.