topic Re: GP client update fails to download, DNS record needed in GlobalProtect Discussions

GP client update fails to download, DNS record needed

MikeSangray2019 — Thu, 16 Nov 2023 15:47:15 GMT

We're updating from 5.2.12 to 6.2.1. The transparent update only works when testing with a DNS entry in a local hosts file. I don't think we've had a DNS entry in the past for the portal, but it seems like it's needed now.

The below article talks about this, but I want to understand which address needs to be resolved. Is it the loopback interface assigned to the portal?

GlobalProtect client upgrades failing to complete. - Knowledge Base - Palo Alto Networks

Re: GP client update fails to download, DNS record needed

aleksandar.astardzhiev — Fri, 17 Nov 2023 14:06:01 GMT

Hi @MikeSangray2019 ,

Thank you for bringing this KB to my attention I was not aware of it.

As mentioned at the beginning of the KB, this is relevant in case your GP portal and GP gateway are hosted on different addresses/devcies.

Can you first confirm your setup is using diffent devices/addresses for GP portal and gateway?

Re: GP client update fails to download, DNS record needed

TomYoung — Fri, 17 Nov 2023 16:18:39 GMT

Hi @MikeSangray2019 ,

If your internal DNS server is also authoritative for your public domain, you have to create an internal DNS entry for the portal in order for GP upgrades to work. Otherwise, your GP client sends the DNS query to the internal DNS server and gets nothing. I create an A record on our internal DNS server for the same name and public IP address assigned to the portal. It is basically a duplicate of the public DNS record, but done internally.

If your internal DNS is not authoritative for your public domain, it should forward the DNS request to the Internet and get the correct public IP address.

I have done this for myself and many customers. I learned this through experience, not any documentation.

Thanks,

Tom

Re: GP client update fails to download, DNS record needed

H00005 — Fri, 21 Nov 2025 08:09:02 GMT

Hi Mike !
We had the same problem because our internal and external domain names were the same. We routed all DNS names related to our domains to our internal DNSes.
You can exclude the DNS name of your portal (MyPublicDNSPortalName.Mydomain.com) to force your client to use its internet access to resolve the name instead of sending it through the split tunneling. It worked for us.

Network > Global Protect > Gateways > Your gateway > Agent > Client Settings > YourClientConfig > Split Tunnel > Domain and application > Exclude Domain

Regards