How to Open a Case on GlobalProtect Remote User VPN Connection Issues

How to Open a Case on GlobalProtect Remote User VPN Connection Issues

35937
Created On 09/25/18 19:03 PM - Last Modified 06/16/23 18:29 PM


Symptom


  • This document shows how to collect preliminary information required by TAC to start working on GlobalProtect (GP) connection issues as soon as a case is opened.


Resolution


  • GlobalProtect involves four major components, so whenever there is an issue, we require logs taken from all these devices at one time.
  • Taking the logs at the same time helps TAC engineers correlate the logs across various devices to better understand at what point the problem happened. 
  • Following are components of GlobalProtect Remote user VPN.
  1. Portal
  2. Gateway
  3. Client
  4. Mobile Device Manager (MDM)
 
  1. Portal
  • The Portal is the main firewall that hosts the configuration to be provided to remote users. Whenever there's an issue regarding GlobalProtect, please try collecting the following information from the portal:
    1. Tech_support file.
    2. System logs – filter the system logs around the same time when the client connects.
    3. Time stamps between which times the issue is seen.
    4. Traffic logs from client public IP to portal IP address. Skip this step if client Public IP is NATed; however, see if there are any logs where traffic to portal IP are discarded.
    5. If the issue is replicable at will, we would request the following debugging steps, to collect information:
      • debug ssl-vpn global on debug 
      • debug rasmgr on debug 
    6. Replicate the issue / Try connecting to portal.
    7. Disable debug by following commands
      • debug ssl-vpn global on info
      • debug rasmgr on normal 
    8. Generate tech_support file
    9. Export system logs within the time frame of replication
    10. Time stamps between which the issue is seen
    11. Traffic logs from client public IP to portal IP address. (Skip this step if client Public IP is NATed, however to see if there are any logs where traffic to portal IP are discarded)
Note: Whenever the client tries to connect to GlobalProtect, the first attempt is made to the portal to get the updated configuration. When failing to connect to the portal, it then uses a cached configuration. The communication to the portal needs to be verified to check if the proper configuration is sent by the firewall.
 
  1. Gateway
  • The Gateway is the firewall to which the user tries to create an encrypted tunnel.
  • If there is a single gateway and portal and they're hosted on the same firewall, the above logs collected for the portal should be sufficient.
  • If the gateway is hosted on a different public IP address on same device, please make sure if there are logs indicating discarded communication to the gateway IP address.  If the gateway is different from the portal, we would require the same information from Gateway:
  1. Tech_support file
  2. System logs – filter the system logs around the same time when the client connects.
  3. Time stamps between which the issue is seen
  4. Traffic logs from client public IP to portal IP address. (Skip this step if client Public IP is NATed, however to see if there are any logs where traffic to portal IP are discarded)

Note: Debugging for Portal and Gateway is the same. Please make sure debugging is turned on and off at the same time on portal and gateway. This helps to compare logs on both devices. In the scenario of complex issues which involve IP tunnel problems for remote users, TAC will reach out for a live debugging session.

  1. Agent
  • The agent software on different operating systems behave differently; however, the communication method of agent with portal and gateway still remains the same.
  • On Windows and Macintosh, we would require to collect debugs under the “Troubleshooting” tab. This tab can be seen under Settings > Troubleshooting. Refer to image 3 in the How to Configure GlobalProtect document.
  • Collect the logs from agent under Settings > Troubleshooting and selecting Collect Logs. GlobalProtect software allows exporting the logs to email.

Note: This is found under the Settings > Troubleshooting tab of the Windows Agent

Snapshot of GlobalProtect agent troubleshooting tab

 

Note: This is found under Settings > Troubleshooting of the macOS Agent.

 

Picture1.png

 

  • If there is a problem with SSO or if there is a third-party credential manager on Windows, then request the following registry information:
    1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\ CurrentVersion\Authentication\Credential Providers
  1. HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\
  • For any connection issue with GlobalProtect while using third-party clients or Xauth, we want to collect any logs from the third-party client or the device regarding this Xauth communication.
  • As stated, please make sure the logs are taken at the same time, and to include the timestamps from client and firewall. This will help to identify issues when client and firewall are in a different time zone.
 
  1. MDM
  • MDM is used for configuring and implementing policies on mobile devices connected to the Global Protect Portal.
  • Whenever there is a problem with MDM related features like enrollment, policy implementation, we would require the following information from MDM.
  • Please make sure that the following information covers the time window when the client tries to connect or when policies are pushed to the clients
    1. Tech_support file.
    2. System logs for the time window when issue is reported.

 



Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/kCSArticleDetail?id=kA10g000000ClTg&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FkCSArticleDetail

Choose Language