You are on page 1of 14

 

Troubleshooting GlobalProtect

Tech Note
PAN-OS 4.1

Revision A ©2012, Palo Alto Networks, Inc. www.paloaltonetworks.com                                                      


 
Contents
SECTION 1: INTRODUCTION ......................................................................................................................................3  
OVERVIEW .......................................................................................................................................................................................3  
Abbreviation .............................................................................................................................................................................3  
Supported Platforms ...............................................................................................................................................................3  
SECTION 2: GLOBALPROTECT ...................................................................................................................................3  
WHAT IS GLOBALPROTECT? ..............................................................................................................................................................3  
Authentication Differences......................................................................................................................................................3  
Server Certificate Verification .................................................................................................................................................4  
Client Certificate Verification ..................................................................................................................................................4  
NetConnect Translation ..........................................................................................................................................................4  
SECTION 3: GLOBALPROTECT CLIENT ARCHITECTURE ............................................................................................5  
GLOBALPROTECT CLIENT WORKFLOW................................................................................................................................................5  
HIP REPORT CHECK MESSAGE..........................................................................................................................................................6  
SECTION 4: GLOBALPROTECT CONFIGURATION .......................................................................................................6  
HOW TO CONFIGURE GLOBALPROTECT GATEWAY ................................................................................................................................6  
General .....................................................................................................................................................................................6  
About Client Certificate ...........................................................................................................................................................6  
Client Configuration.................................................................................................................................................................7  
HIP Notification ........................................................................................................................................................................7  
HOW TO CONFIGURE GLOBALPROTECT PORTAL ..................................................................................................................................7  
Software Download ..................................................................................................................................................................7  
Portal Configuration ................................................................................................................................................................7  
Client Configuration.................................................................................................................................................................8  
SECTION 5: COMMON GLOBALPROTECT DEPLOYMENT ............................................................................................9  
GLOBALPROTECT (DIRECT TRANSLATION FROM NETCONNECT) ............................................................................................................9  
GLOBALPROTECT WITH SAME REACHABLE PORTAL AND GATEWAY ADDRESS (FROM OUTSIDE) ................................................................9  
GLOBALPROTECT WITH ONE TIME PASSWORD AUTHENTICATION SETUP ................................................................................................9  
UNSUPPORTED SETUP ......................................................................................................................................................................9  
SECTION 6: INSTALLATION AND UPGRADE ...............................................................................................................9  
SECTION 7: HOW TO TROUBLESHOOT GLOBALPROTECT CONNECTION ISSUES ..................................................... 10  
WINDOWS LOG FILE .......................................................................................................................................................................10  
MAC OS X LOG FILE .......................................................................................................................................................................10  
PORTAL CONNECTION ISSUES .........................................................................................................................................................10  
GATEWAY CONNECTION ISSUES .......................................................................................................................................................10  
Incorrect Gateway Route Set By GP Client ...........................................................................................................................11  
Wrong Client Certificate Chosen (Mac OS X only) ................................................................................................................11  
No Client Certificate for Gateway (Mac OS X only) ...............................................................................................................11  
Miscellaneous ........................................................................................................................................................................11  
SECTION 8: GLOBALPROTECT UID TROUBLESHOOTING IN PANOS ......................................................................... 12  
SECTION 9: IF IT STILL DOES NOT WORK… ............................................................................................................. 14  
SECTION 10: MISCELLANEOUS ............................................................................................................................... 14  
REVISION HISTORY .................................................................................................................................................. 14  

©2012, Palo Alto Networks, Inc. [2]


Section 1: Introduction
Overview
This document explains how GlobalProtect works and how to troubleshoot it when it does not work as expected. The
target PANOS version is 4.1.x, though most of it still applies to older or newer versions.

Abbreviation
x HIP: Host Information Profile
x GP: Global Protect
x PanGPA: The GlobalProtect UI program
x PanGPS: The GlobalProtect service/daemon program
x OTP: One time password

Supported Platforms
x Windows XP (SP2 and above) / Vista 32/64 bit / 7 32/64 bit
x Mac OS X 10.6/10.7

Section 2: GlobalProtect
What is GlobalProtect?
GlobalProtect is introduced in 4.1 to allow NetConnect to unify with GlobalProtect as NetConnect is not supported
anymore. The unlicensed version of GlobalProtect has the following characteristics:
1. No valid GlobalProtect portal license needed.
2. No HIP report will be sent from client PC.
3. Only 1 external gateway will be sent to the client PC, no matter how many are configured. In general, the first one will
be chosen if there are more than one defined.
4. Support both on-demand and automatic tunnel establishment.
5. No Java is needed.
6. No support for logging in from browser.

If you upgrade from 4.0.x to 4.1.x, the NetConnect configuration will automatically be migrated to the corresponding
GlobalProtect configuration.

The following section will explain the subtle differences between GlobalProtect and NetConnect.

Authentication Differences
In NetConnect, there is no separation between portal and gateway. When user authenticates to the portal, it really
means the gateway. The authentication cookie from the initial login (to the portal) can be used later when the client
connects to the gateway so only one user authentication occurs. However, GlobalProtect has separate portal and
gateway(s) that require separate authentication (even if they reside in the same physical PAN device). For users who
use one time password (OTP) to authenticate, this means they will need to type the OTP twice (one for portal and the
other for gateway in GP). At present, the only workaround is to use static user/password for portal authentication and

©2012, Palo Alto Networks, Inc. [3]


leave the gateway authentication to require OTP. Another workaround is to make the portal only reachable from
inside office. This will force GP client to use the cached portal config file and avoid requesting OTP twice.

Server Certificate Verification


NetConnect does not verify the server certificate while GlobalProtect will verify the following attributes of the server
certificate:
1. The validity of the certificate: Making sure the certificate is not obsolete (it is important to check the time of the
PAN device if it is used to create server certificate)
2. The signer is the one of the CAs defined in the portal config file. (More will be discussed in the portal config
section).

The subject name is NOT verified, meaning one can reuse the same certificate for both portal and gateways.

Client Certificate Verification


NetConnect supports client certificate only via CAC while GlobalProtect supports all client certificates. Since client
certificate is requested by server during SSL handshake, the server (i.e. portal/gateway) must be configured correctly
to request the right client certificate. More will be discussed in the GlobalProtect portal/gateway section.

NetConnect Translation
When NetConnect (prior to 4.1) gets translated into GlobalProtect, the following should happen:
1. Portal and gateway share the same IP address.
2. There is only one external gateway defined in the gateway list.
3. On-demand mode is set to yes.
4. No server certificate or client certificate profile will be configured.

N.B. After the translation, one can always change the on-demand mode and add server/client certificate profile.
However, only one external gateway will be allowed if there is no valid GlobalProtect license.

©2012, Palo Alto Networks, Inc. [4]


Section 3: GlobalProtect Client Architecture
GlobalProtect Client Workflow
GlobalProtect client is a Windows (or Mac) software that runs automatically whenever the client computer restarts. Its
main functionality is to discover the best gateway, establish a secure tunnel to the chosen gateway and upload HIP report
(if needed) to the gateway at a fixed interval.

The following shows the basic workflow of GlobalProtect client:

Get portal Config From portal

No
Successful? Load config from local cache

Yes
No
On-demand mode, wait for user
Auto-connect
to click “Connect”

Yes

Network Discovery

No
Establish secure tunnel to best
Inside Office?
gateway

Yes

Send HIP update to each Send HIP update to external


internal gateway gateway

Figure 1. Basic workflow of GlobalProtect client.

©2012, Palo Alto Networks, Inc. [5]


HIP Report Check Message
GlobalProtect client will send a HIP report check message to each internal gateway or the external gateway once an hour
with some random seconds inserted to even out the loading on the PAN device web server (sslvpn). This message
serves two purposes:
x It serves as a keepalive message to refresh the timeout of the corresponding ip=>user record in data plane.
x It checks if it needs to upload the HIP report to the gateway. The idea being that if there is no change in the HIP
report, the gateway will not need the HIP report again and this saves bandwidth and computing cycles of the
management plane.
Each GP identified user will have 3 hours idle and maximum timeout in the data plane. In addition, the rasmgr will also
use the timeout configuration from the GlobalProtect gateway setting to control the maximum lifetime. Note that the
“Inactivity Logout” defaults to 2 hours which means rasmgr will age out a user if it does not receive a HIP report check
message within 2 hours. To better protect from any networking issue between the client and gateway, the idle timeout
should be set to 3 hours (at least) to allow at least 2 attempts before GlobalProtect loses the IP/user mapping in the data
plane. The “Login Lifetime” controls the absolute maximum lifetime that the tunnel/user should be allowed to exist. Its
main purpose is to reclaim the limited resource in data plane in case there are lots of tunnel users.

Section 4: GlobalProtect Configuration


How to Configure GlobalProtect Gateway
There are mainly three major components when configuring GlobalProtect gateway: General, Client Configuration and
HIP Notification.

General
In the general section, the Authentication section is for configuring the “Server Certificate”, “Authentication Profile”
and “Client Certificate Profile”.
Server certificate can either be self-signed or issued by a trusted CA. If it is issued by a trusted CA, the CA must be
set in the “Root CA” list of the GlobalProtect portal configuration. As mentioned above, GP client only verifies that
the server certificate is signed by the trusted CA (from the Root CA list) and the validity (within the valid dates). GP
client does not check the Subject name. If the server certificate is signed by an intermediate CA, both CAs will need to
be in the Root CA list or the intermediate CA must be stored in the Intermediate Certification Authorities in Windows
or Keychain in Mac.
The Authentication Profile controls how the user should be authenticated. All PANOS supported methods like Radius,
LDAP, Kerberos or Local database.
The Client Certificate Profile controls if (and which) client certificate is needed for SSL handshake. The CA
Certificates in the Client Certificate Profile defines the acceptable client certificate that gateway expects. If CAC is
used, user can further specify the Username field in the profile that the gateway should extract as the user name of
the user.

About Client Certificate


If Client Certificate Profile is set for the gateway, it means a valid client certificate is needed. There are three places
that GlobalProtect client can retrieve client certificate:
1. From the portal config file (one can define a client certificate in the portal config)
2. From the CAC card (dynamically retrieved)
3. From the certificate store in Windows or Keychain in Mac.

The simplest way is to define it in the portal config but it means portal authentication CANNOT configure Client
Certificate Profile.

©2012, Palo Alto Networks, Inc. [6]


Client Configuration
This section configures the DNS, WINS, access routes and IP pool for the tunnel. It is very straightforward.

HIP Notification
HIP notification allows administrator to configure what/how to notify user when they either match or not match a HIP
profile. It is mainly used to alert user when they are not in compliance with corporate policy, e.g. they did not enable
anti-virus protection or their PCs are not patched to the latest service packs, etc.

How to Configure GlobalProtect Portal


GlobalProtect portal controls two major components of GlobalProtect: The software download/upgrade and the portal
config file.

Software Download
If user uses a browser to access the portal login page via https://<portal_address/name>/, it will be presented with a
login page (customizable via the “Custom Login Page” in portal config). After authentication, the user should see a
page similar to below:

Just click on the appropriate link for the OS and installs the GlobalProtect client software. It will ask you to specify
the portal address (and user credential if SSO is not enabled or it is Mac).
GlobalProtect portal has two components: portal Configuration and Client Configuration.

Portal Configuration
In the portal Configuration, the key attributes that are interesting are: Authentication Profile, Client Certificate, Server
Certificate and Client Certificate Profile.
Authentication Profile, Server Certificate and Client Certificate Profile are exactly the same as that of GP gateway.
Please refer to the gateway configuration above for detailed explanation. The client certificate is only for portal
Configuration. This defines the client certificate that GP client should use when connecting to gateway. Note that
client certificate profile should be set to None if client certificate is defined or else it will create a catch-22 scenario
that GP client cannot connect to the portal to get the config file because it needs the client certificate from the config
file to satisfy the SSL handshake. Some common deployment scenarios are described in following sections.

©2012, Palo Alto Networks, Inc. [7]


Client Configuration
Client configuration controls most of the behavior of GP client.

Source  User  
It supports user/group specific configuration to allow more granular control on which users should get what portal
config. Admin can specify users or groups.

Root  CA  list  


This configures the CA list that GP client should use to verify the server certificate. If it is self-signed certificate,
nothing needs to be configured in the Root CA list.

Gateways  
One defines the internal and external gateways here. For internal gateway, GP client can establish tunnel to ONE of
the internal gateways and send HIP check/report message to all internal gateways. For external gateway, GP client
always measure the latency of each external gateway and select the best one to establish tunnel. The priority
attribute can be used to allow GP client to favor gateway that has a LOWER priority value (1 is the highest priority and
5 is the lowest).

Internal  Host  Detection  


Internal Host Detection provides hints to GP client to determine quickly if the PC is inside or outside office. If it is not
configured, GP client will always try to connect to each internal gateway first. If it fails to connect to any internal
gateway or if there is no internal gateway defined, it will then attempt to connect to the best external gateway. Admin
should try to set internal host detection as it speeds up the tunnel establishment.

On  Demand  
If checked, this will change GP client to on demand mode. User has to use the “Connect” menu item to tell GP client
to establish tunnel. Note that internal host detection IS IGNORED in on-demand mode. GP client will always attempt
to try internal gateways first followed by external gateways. It is definitely NOT a good idea to set up both internal
and external gateways for on demand mode. The most common use case is to configure a single external
gateway for on demand mode, simulating NetConnect functionality.

Use  Single  Sign  On  (for  Windows  only)  


If enabled, the Windows GP client will try to use the Windows login credential to authenticate the user. Note that one
must log off once after installation before GP client can use SSO.

Third  Party  VPN  


Admin can specify the substring of the supported third party VPN clients that GP client should allow to run
simultaneously. If split tunneling is used for GlobalProtect (not common), GP client will increase the metric of its own
routes to let the OS favor the third party VPN client’s access routes. If only default route is set for GlobalProtect, GP
client will only increase its own metric if the third party VPN client also uses default route.

Data  Collection  
Admin can specify which categories should be excluded from HIP report collection (to save CPU cycles and improve
response time in client) as well as what custom checks to collect. The custom checks are case insensitive. The
maximum wait time specifies how long the GP client can use to collect the HIP information from the client PC. A
value of 60 seconds is a good start for most PC.

Agent  Override  
Admin can specify that a user can “disable” GP client in case it interferes with his/her network access. It can be
configured with “with-comment”, “with-passcode” or “with-ticket”. “with-comment” means any comment specified
by user can disable the client. “with-passcode” is a admin configured static passcode in the portal config. “with-
ticket” is new in 4.1 and more secure. If it is configured with “with-ticket”, a new ticket is required for each override.
The user needs to use the client to generate a “request” and let administrator set in the CLI

©2012, Palo Alto Networks, Inc. [8]


“request global-protect-portal portal <portal_name> duration <minutes> request <from UI>”
This will generate a ticket that the user needs to type in the dialog to disable GP client. A new ticket is required after
it expires or the usage count exceeds the maximum allowable value (defined by the attribute max-agent-user-
overrides).

Section 5: Common GlobalProtect Deployment


GlobalProtect (Direct Translation from NetConnect)
This means the PAN device does not have a valid GP portal or gateway license. When GP client requests the portal config
file from portal, only one external gateway will be listed. The most common setup will be
x Portal and gateway share the same IP address
x No client certificate or client certificate profile configured
x On-demand mode
x (No HIP collection)

This is more or less like NetConnect. If it is not in on demand mode, GP client will automatically establish tunnel to the
only external gateway whenever the user logs into the PC. As mentioned above, internal host detection will be ignored in
on demand mode so it is best to skip configuring it in on demand mode. Administrator can certainly add the client
certificate profile (to gateway only) and client certificate to make the connection more secure. Unless the client
certificate already exists in the client PC, it is best to specify no client certificate profile for portal authentication.

GlobalProtect with Same Reachable Portal and Gateway Address (From Outside)
This is common for customer with only one reachable IP address from outside and only one gateway license. It is not
much different from GlobalProtect except HIP will be collected from client PC and uploaded to the gateway if needed.
Again, one should configure portal to have no client certificate profile to avoid the chicken and egg issue mentioned
previously unless CAC is used. In that case both portal and gateway should be configured with the same client certificate
profile.

GlobalProtect with One Time Password Authentication Setup


For some customers, one time password is required for any access from outside. Since GlobalProtect requires both a
portal and gateway authentication, this will cause problems as the first OTP will not work on the subsequent gateway
authentication. There are two workarounds for this setup:
1. Use separate IP address for portal and gateway and make the portal reachable from inside office only. This will
force GP client to use cached portal config and avoid using the OTP for the gateway.
2. Use different authentication profile for profile that does not require OTP. This may be acceptable to customers as
portal config does not contain any sensitive data. GP client connects to portal for the config file only.

Unsupported Setup
GlobalProtect cannot support different client certificates between portal and gateway(s) or between different gateways.

Section 6: Installation and Upgrade


The installation package links are presented after a successful login to the portal from any web browser. One needs to
select the appropriate link to download and install the package. Administrator right is required for initial installation.
Subsequent upgrade/downgrade can be executed by users without administrator privilege.
For Windows, the installation log is stored in the installation directory, e.g. c:\program files\palo alto
networks\GlobalProtect\PanGPMsi.log.
For Mac, the installation log is stored in /Library/Logs/PaloAltoNetworks/GlobalProtect/PanGPInstall.log
In case installation fails, this file can shed some light on what went wrong.

©2012, Palo Alto Networks, Inc. [9]


During normal uninstallation, the last connected portal address and saved encrypted user credential are still stored in
registry. To completely remove any trace of GlobalProtect, it is best to remove the following registry keys:

HKEY_LOCAL_MACHINE\Software\Palo Alto Networks\GlobalProtect

HKEY_CURRENT_USER\Software\Palo Alto Networks\GlobalProtect

and everything in the installation directory.

For Mac OS X, the installation directory is /Applications/GlobalProtect.

Section 7: How to Troubleshoot GlobalProtect Connection Issues


Windows Log File
For Windows, the two key log files are PanGPS.log (in installation directory) and PanGPA.log (user’s top level profile
directory). The PanGPS.log logs every connection attempt and all errors encountered by the PanGPS service. This is the
most important log file that allows engineering to figure out what’s going on.

Mac OS X Log File


For Mac OS X, the two log files PanGPS.log are also stored in separate directories.
PanGPS.log: /Library/Logs/PaloAltoNetworks/GlobalProtect/PanGPS.log
PanGPA.log: ~/Library/Logs/PaloAltoNetworks/GlobalProtect/PanGPA.log

Portal Connection Issues


If GP client cannot connect to the portal, the first thing user should do is to use a web browser to try to access the portal.
If the login page is displayed, that means the portal is reachable. In this case one should set the debug level to “Debug” in
the troubleshooting tab in the GP client for PanGP Service. The log file “PanGPS.log” (in the installation directory, e.g.
c:\program files\palo alto networks\globalprotect\PanGPS.log) should reveal the issue. Common failures are:
1. Invalid server certificate - This can be caused by an incorrect server clock when the server certificate is issued
or the CA for the server certificate is incorrectly set or not set. Another possibility is that the certificate chain is
not inside the portal config file. You need to either install the whole chain in the certificate store in Windows or
Keychain in Mac to allow GP client to verify the server certificate or they must be included in the portal config.
The PanGPS.log should indicate that server certificate is invalid and provides some reasons for it.
2. Invalid user credential - It may be either incorrect password or the password contains special characters (e.g.
‘&’, ‘<’, ‘>’, etc) that older versions of GlobalProtect portal cannot handle. Version 4.1.3 and above should not have
this issue. Checking the authd.log from PAN device may also indicate authentication failure if the password is
indeed incorrect.
3. Invalid client certificate - This is mostly due to incorrect portal configuration that requires client certificate but
the PC does not have the appropriate one.

In general, the authd.log, sslvpn-access.log and sslvpn-error.log in PAN device may provide more insight on why the
connection fails.

Gateway Connection Issues


There are many ways gateway connection can fail. Common failures include the ones mentioned above for the portal. In
addition, it can also be caused by incorrect gateway route set by GP client.

©2012, Palo Alto Networks, Inc. [10]


Incorrect Gateway Route Set By GP Client
This only happens to Windows 7 client as the OS remembers the routes for a virtual interface. For a typical setup that
uses default route, the following routes are normally set by GP client:
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.16.0.1 10.16.0.209 20
0.0.0.0 0.0.0.0 10.20.0.1 10.20.1.205 25
0.0.0.0 0.0.0.0 On-link 88.88.88.1 1
10.0.0.246 255.255.255.255 On-link 88.88.88.1 1
10.0.0.247 255.255.255.255 On-link 88.88.88.1 1
10.1.8.150 255.255.255.255 10.16.0.1 10.16.0.209 21

In above example, the assigned IP is 88.88.88.1 and the two DNS servers are 10.0.0.246 and 10.0.0.247. The GP
gateway is 10.1.8.150. The ones in blue and red are all installed by GP client after it establishes a secure tunnel with
the gateway. The one in red is the most important as it allows the GP client to reach the gateway. In previous
releases (before GP 1.1.3), there is a chance that the specific route to the gateway is set incorrectly due to Windows
7’s behavior and one may see the following:

IPv4 Route Table


===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.16.0.1 10.16.0.209 20
0.0.0.0 0.0.0.0 10.20.0.1 10.20.1.205 25
0.0.0.0 0.0.0.0 On-link 169.254.195.172 1
10.0.0.246 255.255.255.255 On-link 169.254.195.172 1
10.0.0.247 255.255.255.255 On-link 169.254.195.172 1
10.1.8.150 255.255.255.255 On-link 169.254.195.172 21

Or the gateway route is pointing back to the assigned IP. In either case it will cause a loop and no traffic can go out,
thus causing GP client to disconnect right away. To help identify this scenario, please ask customer to issue the
command “route print” to print out the route table while it is connecting to the gateway. This should be fixed in 1.1.3
and above.

Wrong Client Certificate Chosen (Mac OS X only)


Mac OS X supports wildcard in domains for Keychain Access Identity preference. In some Mac computers, a specific
client certificate is set to be used for all domains (i.e. wildcard used for the domain name). This will obviously cause
the wrong client certificate to be sent to the portal/gateway and cause the connection to fail. If this happens, one has
to open the Keychain access and remove that Identity preference.

No Client Certificate for Gateway (Mac OS X only)


If the portal and gateway share the same IP address and the portal is configured to not require client certificate (i.e.
no client certificate profile set against portal). Mac OS X will cache the “answer” for 10 minutes and may cause the
gateway connection to fail because the OS will refuse to send the client certificate to the gateway (it thinks that it does
not need to from the response of the previous portal connection). GlobalProtect works around this issue by restarting
PanGPS to remove the cache. This should at most affect the user once. After GP client install the client certificate to
the Keychain, it will be able to use the same certificate for both portal and gateway subsequently.

Miscellaneous
Sometimes the issue is with PAN device and the following files may indicate why it fails.

©2012, Palo Alto Networks, Inc. [11]


authd.log  (less  mp-­‐log  authd.log)  
This is the authd debug log file and contains all authentication related logs. If needed, one may set the log level to
“debug” to help troubleshoot authentication related issues.

sslvpn-­‐access.log  (less  webserver-­‐log  sslvpn-­‐access.log)  


This is the sslvpn (web server) access log file and contains all URLs accessed from the web server. It can be used to
check if the GP client actually reaches the PAN device and together with other log files to figure out the issue. Typical
logs that indicate the GP client can reach the portal/gateway are as follows:

10.16.0.209 - - [Thu Feb 02 10:16:25 2012 PST] "POST /global-protect/prelogin.esp HTTP/1.1" 200 635
10.16.0.209 - - [Thu Feb 02 10:16:25 2012 PST] "POST /global-protect/getconfig.esp HTTP/1.1" 200 12714
10.16.0.209 - - [Thu Feb 02 10:16:26 2012 PST] "POST /ssl-vpn/prelogin.esp HTTP/1.1" 200 634
10.16.0.209 - - [Thu Feb 02 10:16:29 2012 PST] "POST /ssl-vpn/login.esp HTTP/1.1" 200 921
10.16.0.209 - - [Thu Feb 02 10:16:29 2012 PST] "POST /ssl-vpn/getconfig.esp HTTP/1.1" 200 982
10.16.0.209 - - [Thu Feb 02 10:16:41 2012 PST] "POST /ssl-vpn/hipreportcheck.esp HTTP/1.1" 200 350
10.16.0.209 - - [Thu Feb 02 10:16:42 2012 PST] "POST /ssl-vpn/hipreport.esp HTTP/1.1" 200 553

POST  /global-­‐protect/prelogin.esp  
This is the prelogin to the GlobalProtect portal. It is used to check if the portal has license and whether client
certificate is needed and the username to submit (for CAC). GlobalProtect client relies on this to know whether it is in
GlobalProtect licensed or unlicensed mode.

POST  /global-­‐protect/getconfig.esp  
This is to get the portal config file from the GlobalProtect portal. A HTTP 200 normally means it is successful.

POST  /ssl-­‐vpn/prelogin.esp  
This is the prelogin to the GlobalProtect gateway. It is used to check if the gateway has license and whether client
certificate is needed and the username to submit (for CAC).

POST  /ssl-­‐vpn/login.esp  
This is to log into the GlobalProtect gateway. Upon successful login, a valid authentication cookie will be provided to
the GP client for subsequent connections to the gateway (like HIP check message, HIP report upload, etc).

POST  /ssl-­‐vpn/getconfig.esp  
This is to get the gateway config that defines the tunnel parameters.

POST  /ssl-­‐vpn/hipreportcheck.esp  
This is the HIP check message that GP client uses to check if it needs to send the HIP report to the gateway(s). In
addition, this message is used by web server (SSLVPN) to refresh the IP/user mapping record in dataplane. If the web
server does not see this message for more than 3 hours, the IP/user record will be removed from the dataplane.

POST  /ssl-­‐vpn/hipreport.esp  
This is the HIP report upload message that GP client uses to send the HIP report to the gateway(s). This will trigger
the useridd daemon to match the HIP profiles again and update all records accordingly.

The hipreportcheck.esp and hipreport.esp are proof that GP client sends update to the gateway. If one cannot see
that from the sslvpn-access.log file, the IP/user record will time out after 3 hours.

Section 8: GlobalProtect UID Troubleshooting in PANOS


There are many daemons in PANOS that are related to GlobalProtect. The following highlights some of the CLI
commands that administrator can use to troubleshoot GP user/ip mapping and HIP profile matches issue.

©2012, Palo Alto Networks, Inc. [12]


Each security policy rule can have up to 63 HIP profiles defined. Whenever a HIP report is received by useridd daemon, it
will be matched against all configured HIP profiles to create the IP => user => HIP profile matches relationship in both
control and data planes. If one wants to check the individual HIP match in detail, one can enable “debug” in useridd with
the following commands:
debug user-id on debug
debug user-id set hip detail

This will allow useridd daemon to output more verbose logs about the HIP matches.

To see the actual IP => user mapping in data plane, one can use the following command:

admin@PA-4020> show user ip-user-mapping

IP Ident. By User Idle Timeout (s) Max.


Timeout (s)
--------------- --------- -------------------------------- ---------------- ----
------------
88.88.88.1 GP paloaltonetwork\sleung 9745 9745

Total: 1 users

By default, each record should have “GP” and 3 hours idle/max timeout. The timeout should be refreshed whenever the
HIP check/report message arrives at the SSLVPN web server.
To show the actual HIP profiles for the user, one can add the “detail yes” to show complete detail about the IP/user
mapping record in dataplane.
admin@PA-4020> show user ip-user-mapping detail yes

IP address: 88.88.88.1
User: paloaltonetwork\sleung
Ident. By: GP
Idle Timeout: 9711s
Max. TTL: 9711s
Groups that the user belongs to (used in policy)
HIP profiles that user belong to (used in policy)
HIP profile(s): MSFW-is-installed-profile

To show the whole HIP profile database in control plane, one can use the following CLI:
admin@PA-4020> debug user-id dump hip-profile-database

Total number of hipmask in database: 1


Total size of hip reports: 3912KB used / 1248256KB
Entry User Computer
IP TTL VSYS HIP Profile
----------------------------------------------------------------------
1 paloaltonetwork\sleung PAN01141
88.88.88.1 9560 vsys1 MSFW-is-installed-profile
----------------------------------------------------------------------
1-1 records shown

To show the raw HIP report of a particular user, one can use the following CLI:
admin@PA-4020> debug user-id dump hip-report user paloaltonetwork\sleung ip 88.88.88.1 computer PAN01141

<?xml version="1.0" encoding="UTF-8"?>


<hip-report>
<md5-sum>ae413e22b34a76366a542a1dd9b1108a</md5-sum>
<user-name>sleung</user-name>
<domain>PALOALTONETWORK</domain>
<host-name>PAN01141</host-name>
<ip-address>88.88.88.1</ip-address>
<generate-time>02/08/2012 10:21:06</generate-time>
<categories>

</categories>
<categories>

</categories>
</hip-report>

©2012, Palo Alto Networks, Inc. [13]


Section 9: If It Still Does Not Work…
To expedite any troubleshooting about GP client related issues, please collect the following to allow quick diagnostics by
engineering.

-­‐ PAN Device Techsupport bundle.


This is needed for us to know the portal/gateway configuration as well as the certificate setup as well as the
PANOS version.

-­‐ Client side techsupport file (Use the “PanGPSupport” program) to collect client side log files. Before collecting
the client side logs, please set log level (in Troubleshooting tab) to “Debug” or “Verbose” and click “Rediscover
Network” once to allow more complete capture of the whole connection. In general, it is okay to set the log level
to “Debug” without impacting performance. This will help us tremendously to understand why GP client fails.

Section 10: Miscellaneous


We have seen a few cases where customers report that they can’t use OTHER VPN clients like Cisco AnyConnect, Avaya,
etc. to maintain IPSEC connection to the GlobalProtect gateway. The only client supported is the GP client for Windows
and Mac OS X. GP gateway also supports the built-in iOS Cisco VPN client via XAuth for IKE (not covered in this document).

Revision History
Date Revision Comment
2/6/2012 00A Initial draft

©2012, Palo Alto Networks, Inc. [14]

You might also like