Professional Documents
Culture Documents
Troubleshooting GlobalProtect
Tech Note
PAN-OS 4.1
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
The subject name is NOT verified, meaning one can reuse the same certificate for both portal and gateways.
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.
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
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.
The simplest way is to define it in the portal config but it means portal authentication CANNOT configure Client
Certificate Profile.
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.
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.
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.
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).
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.
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
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.
Unsupported Setup
GlobalProtect cannot support different client certificates between portal and gateway(s) or between different gateways.
In general, the authd.log, sslvpn-access.log and sslvpn-error.log in PAN device may provide more insight on why the
connection fails.
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:
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.
Miscellaneous
Sometimes the issue is with PAN device and the following files may indicate why it fails.
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.
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:
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
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
-‐ 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.
Revision History
Date Revision Comment
2/6/2012 00A Initial draft