GlobalProtect client upgrades failing to complete

GlobalProtect is configured on the portal to allow client upgrades either transparently or manually. When an upgrade begins (transparently or manually), the process starts but fails to complete.

GlobalProtect with client upgrades enabled in the portal configuration (transparent or manual).

This issue occurs specifically when the portal and gateways are hosted on different IP addresses, as the GlobalProtect client attempts to download the update from the portal through the GlobalProtect tunnel.

The logs indicate that the upgrade process 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:

• DNS Resolution: When the client connects to the gateway, it must be able to resolve the portal's hostname. If the client's DNS servers change upon connecting to the gateway and cannot resolve the portal hostname, the file download will fail.
• Security Policy: If name resolution is working, verify that a security policy allows access to the portal through the tunnel on the gateway. Before connecting to GlobalProtect, the client accesses the portal directly. Once connected, traffic routes through the GlobalProtect tunnel. If there is no security policy permitting this, the traffic is denied.

Traffic logs example:

1. Accessing the portal via a web browser before connecting succeeds because the traffic flows directly within the same zone (L3-Trust to L3-Trust).
2. Once the GlobalProtect client connects, web browser access to the portal is blocked because traffic originates from the L3-GP zone (assigned to the GlobalProtect tunnel), and no rule permits L3-GP to L3-Trust traffic.

Test topology:

This scenario was tested using a single firewall with the gateway configured on the L3-Trust interface and the portal configured on a loopback interface within the same zone, but assigned a different IP address from the gateway.

Key factors:

The gateway and portal use different IP addresses and the access routes provided to the GlobalProtect client force traffic destined for the portal through the GlobalProtect tunnel once connected.

Test security policy:

       1. Initial portal and gateway connectivity for the client is permitted because both reside in the L3-Trust zone.
       2. After connecting, the client resides in the L3-GP zone. The current security policy permits traffic from L3-GP to L3-Untrust, but not to L3-Trust (where the portal's loopback address resides).

1. Ensure the client can still resolve the portal hostname after connecting to the gateway.
2. Configure a security policy on the gateway to allow connectivity from the GlobalProtect client zone/IP pool to the portal IP/zone.

Reachability to the portal image download directory can also be tested by asking an affected user to enter the following URL into their browser while connected to GlobalProtect:

https://<portal FQDN>/global-protect/getsoftwarepage.esp