Palo Alto Networks Knowledgebase: Captive Portal Using Transparent or Redirect Mode in Vwire Deployment

Captive Portal Using Transparent or Redirect Mode in Vwire Deployment

7334
Created On 02/08/19 00:07 AM - Last Updated 02/08/19 00:08 AM
User-ID
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.

 

cp_server_cert.jpg

 

 

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

 

ldap_auth.jpg

 

 

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

 

captive_portal.jpg

 

 

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

 

cp_policies.jpg

 

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.

 

Screenshot from 2015-01-27 06 55 30.png

 

 

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.

 

Screenshot from 2015-01-27 06 57 29.png

 

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

 

Screenshot from 2015-01-27 08 31 19.png

 

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.

 

certs.jpg

 

 

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.

 

export.jpg

 

 

import.jpg

 

 

 

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.

 

privatekey.jpg

 

 

clientcert.jpg

 

 

 

The same Captive Portal Policies apply as shown below.

 

cp_policies.jpg

 

 

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.

 

client_cert_profile.jpg

 

 

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.

 

redirectmode.jpg

 

 

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

 

interfaces.jpg

 

 

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.

 

clientcertificate.jpg

 

 

iejimmyr.jpg

 

 

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.

 

Screenshot from 2015-01-27 13 25 51.png

 

Screenshot from 2015-01-27 13 25 29.png

 

 

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

 

 

 

Screenshot from 2015-01-27 13 29 21.png

 

 

Finally, the original requested website is presented to the user

 

Screenshot from 2015-01-27 13 29 44.png

 

 

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.

 

keychain_trustedcert.png

 

 

keychain_clientcert.png

 

 

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

 

macos_client_cert.png

 

 

66215_macos_espn_site.jpg

 

 

 

admin@lab-26-PA5050> show user ip-user-mapping all

 

IP Vsys   From    User                             IdleTimeout(s) MaxTimeout(s)

--------------- ------ ------- -------------------------------- -------------- -------------

  1. 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)

--------------- ------ ------- -------------------------------- -------------- -------------

  1. 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.    



Attachments
Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClJYCA0&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Attachments
Choose Language