GlobalProtect client upgrades failing to complete.
54941
Created On 03/08/19 08:16 AM - Last Modified 05/01/20 02:47 AM
Symptom
GlobalProtect is configured on the portal to allow client upgrades either transparently or manually. When the upgrade is started either manually or transparently, the process starts but does not complete.
Environment
GlobalProtect with client upgrade allowed on the portal configuration (either transparent or manual).
Cause
The issue is specifically if the portal and gateways are hosted on different IP addresses as the GlobalProtect client will try and download the update from the portal through the GlobalProtect tunnel.
The errors below show that the upgrade starts but the file download fails.
(T14088) 03/08/19 17:31:50:199 Error( 291): CPanHTTPSession::SendRequest: WinHttpSendRequest failed with error 12002.
(T14088) 03/08/19 17:31:50:199 Error( 148): DownloadURLToFile: download failed
(T14088) 03/08/19 17:31:50:199 Error( 361): CPanHTTPSession::DownloadData: WinHttpQueryHeaders failed with error 12019.
(T14088) 03/08/19 17:31:50:199 Error( 167): DownloadURLToFile: cancel download
(T14088) 03/08/19 17:31:50:199 Info (2375): DownloadProc: download file failed.
Things to check are:
- When the client is connected to the gateway, it should be able to resolve the portal hostname. If the DNS servers change when connected to the gateway and for some reason, they cannot resolve the portal hostname, the file download will fail.
- If name resolution works ok, there should be a policy to allow the portal access through the tunnel on the gateway. As seen in the logs below, prior to the GlobalProtect client being connected, the portal (192.168.0.1) is accessed directly but once the client is connected the traffic goes through the GlobalProtect tunnel and as there is no security policy the traffic is denied.
Traffic logs:
- Accessing the portal via browser shows the connection is allowed in this case as it is directly from L3-Trust to L3-Trust.
- Once the GlobalProtect client is connected, access to the portal via browser is blocked because the traffic is from the L3-GP zone which is for the GlobalProtect tunnel and there is no rule to allow the traffic.
Test Topology:
This was tested using a single firewall with the gateway configured on the L3-Trust interface and the portal configured on a loopback interface also on the L3-Trust but a different IP address to the gateway.
Key points are the gateway and portal are different IP addresses and the access routes provided to the GlobalProtect client mean traffic to the portal is routed through the GlobalProtect tunnel when connected.
Test Security policy:
The portal and gateway connectivity for the client are allowed as both are on the L3-Trust zone.
Once the client connects it will be in the L3-GP zone. The policy allows the L3-GP zone to L3-Untrust but not L3-Trust which is the zone where the portal loopback address is.
Resolution
- Make sure the client is still able to resolve the portal hostname when connected to the gateway.
- Ensure the security policy on the gateway will allow the connectivity from the GlobalProtect client IP/Zone to the portal.