Issues related to GlobalProtect can fall broadly into the following categories:
– GlobalProtect unable to connect to portal or gateway
– GlobalProtect agent connected but unable to access resources
This article lists some of the common issues and methods for troubleshooting GlobalProtect. The article assumes you are aware of the basics of GlobalProtect and its configuration. Refer to the GlobalProtect resource guide.
Tools used for troubleshooting
Tools and utilities for troubleshooting on the client machine
To verify reachability to the portal/gateway
To make sure that the FQDNs for the portal/gateway are getting resolved
Ipconfig/ Ifconfig/ Netstat -nr / Route print
To verify the GlobalProtect adapter settings and routes installed by the GlobalProtect client
MMC (Windows)/Keychain Access (OSX)
To install and verify the installed client/root CA certificates
To capture transaction between the GlobalProtect client and the portal/gateway
To download the GlobalProtect client and to confirm successful SSL connection between the client and the portal/gateway
GlobalProtect Client Status/Detail tab
|To check the status of the connection|
|GlobalProtect client logs||To check detailed debug logs from the GlobalProtect client|
3) Use nslookup on the client to make sure the client can resolve the FQDNs for the portal/gateway.
4) Open a web browser and enter the URL : https://<Portal-IP/FQDN> and/or https://<Gateway-IP/FQDN>. This will make sure that the SSL communication between the client and the portal/gateway is working fine. The web browser easily helps us check the certificate coming from the portal/gateway. If there are certificate issues, browser errors can help isolate those. Below are some examples:
5) If the browser page above is not loading properly, check with Wireshark to see if the TCP handshake is complete or not. Use filter ip.addr==<Portal IP> or ip.addr==<gatewayIP> as appropriate.
6) If the SYN packet is going out and no ACK is received, move to the firewall and see if the sessions are getting formed, and if packets are getting dropped. Use dataplane debugs or captures combined with global counters to check the same. Check security policies, NAT, etc. to make sure traffic is not getting dropped.
7) In the above case, sometimes it is also helpful to check if dataplane resources are healthy. Check the following commands to find any resource over-utilization:
> show running resource-monitor
> debug dataplane pool statistics
8) Check appweb3-sslvpn.log for more information, if packets are not getting dropped on the dataplane.
9) From the browser, if the GlobalProtect login page is loading properly, it might ask for the client certificate if client certificate-based authentication is enabled on the portal.
10) Check whether the proper client certificate is loaded into the machine's certificate store, and the browser’s certificate store.
11) If you are getting the error 'valid Client Certificate is required,' import the client certificate into the browser and the client machine.
'Valid client certificate is required' error accessing portal address on Firefox
Internet Explorer Browser Error: "Valid client certificate required"
12) Try logging in to the GlobalProtect Portal Web page. This will confirm that the authentication is working fine.
13) If unable to log in, check the firewall authd logs to see what is the error. The following document can be helpful if using LDAP authentication: How to Troubleshoot LDAP Authentication
14) If you are able to login in to the Portal Web page, download and install the GlobalProtect client, if not already installed.
15) Open the GlobalProtect client, and enter the required settings (Username/ Password / Portal) and click Apply.
16) Notice the message displayed on the Status tab.
17) Collect the logs on the GlobalProtect client, as mentioned in the tools used section, and open the PanGPS.log file in the zipped folder.
18) Go through the logs, and based on error messages, take corrective action or troubleshoot.
19) Simultaneously, you might be required to check the mp-log/appweb3-sslvpn.log on the firewall for more information.
After following the above troubleshooting approach, if you are receiving the following errors:
1) Could not connect to Portal (or similar symptoms)
– GlobalProtect Client Error: did not find portal address
– GlobalProtect Client not Connecting
– GlobalProtect Client Stuck at Connecting when Workstation is on the Local Network
– GlobalProtect Client Unable to Connect on Newly Installed Machine
2) Required client certificate is not found
– GlobalProtect failed to connect - required client certificate is not found
3) 'Server certificate verification failed' or 'Protocol error. Check server certificate
– GP Client Error: Gateway Protocol Error, Check Server Certificate
– Unable to Access GlobalProtect Due to Error (3659)
4) Failed to SetDoc. Message: errors getting GlobalProtect config
– GlobalProtect Client Error: "Failed to SetDoc. Message: errors getting GlobalProtect config"
5) [OCSP] The result of Certificate status query is unavailable
– OCSP Validation of Client Certificate Not Working
6) Discovering Network
– How To Troubleshoot Driver Issues in GlobalProtect that cause "Discovering Network" to be stuck.
7) IpReleaseAddress failed: The RPC server is unavailable
8) Element not found
9) Failed to find PANGP virtual adapter interface
10) Failed to get default route entry
11) Cannot connect to root\cimv2
12) Assign private IP address failed
GlobalProtect agent connected but unable to access resources
1) Check whether the GlobalProtect Client Virtual Adapter is getting an IP address, DNS Suffix and Access Routes for the remote resources. You can use the GlobalProtect Client Panel Detail tab or the command line tools like ipconfig/all, ifconfig, nslookup, netstat -nr, route print etc. for the same.
2) Check to see that port 4501 is not blocked on the Palo Alto Networks firewall or the client side (firewall on PC) or somewhere in between, as this is used by IPsec for the data communication between the GlobalProtect client and the firewall. Pcaps on the client physical interface or pcaps and debugs on the firewall can help to make sure packets are not getting dropped anywhere.
3) Check whether the Firewall is configured with proper security policies to allow the traffic from the IP pool allotted to the GlobalProtect Client Virtual Adapter. The policy should be configured from the zone of the tunnel interface to the zone of the protected resource. Tools like traffic logs, packet captures, dataplane debugs with global counters can be used to troubleshoot this. Packet captures on the Client on the GlobalProtect Adapter can help to compare the packets as sent by the client with what is received on the firewall and vice versa.
4) Check for SSL decryption being enabled for GP traffic, which could break any browser-based or non-browser application's traffic.
5) Check whether there is proper route for the IP pool used by GlobalProtect on the network for reply traffic. If you are using dynamic routing, then you need to redistribute these routes to the routing protocol from Palo Alto Networks. Captures on the Palo Alto Networks firewall for unencrypted traffic can help find out if firewall is sending the packets out towards the resources and if it is getting any response.
6) Check whether the Firewall is getting the IP-User Mapping from the GlobalProtect client. Verify using > show user ip-user-mapping ip <ip> to make sure the firewall is able to find the group the user is a part of. If the group mapping is not populated properly, then troubleshoot the User-ID issue.
Troubleshooting User-ID: Group and User-to-IP Mapping
User-ID resource list
7) Check whether the firewall is getting the HIP data from the GlobalProtect Client, and if the HIP object is configured properly and allowed in the security rule. How to Troubleshoot HIP Data