Windows GlobalProtect Client Takes A Long Time To Connect
25104
Created On 09/01/21 19:00 PM - Last Modified 04/23/24 03:26 AM
Symptom
- GlobalProtect connection taking over a minute to connect
- In PanGPS.log see "DnsQuery returns 1460"
(P20096-T14052)Debug(1925): 06/18/21 18:49:41:649 Retry DnsQuery. (P20096-T14052)Debug(1943): 06/18/21 18:49:41:649 Already takes 12 seconds for all dns queries. (P20096-T14052)Debug(1917): 06/18/21 18:49:42:691 DnsQuery returns 1460 (P20096-T14052)Debug(1925): 06/18/21 18:49:45:697 Retry DnsQuery. (P20096-T14052)Debug(1943): 06/18/21 18:49:45:697 Already takes 16 seconds for all dns queries. (P20096-T14052)Debug(1917): 06/18/21 18:49:46:734 DnsQuery returns 1460
- Affecting Windows users after Windows Update - KB5001330
Environment
- GlobalProtect for Windows
- Windows Update - KB5001330
- Internal Host Detection configured
Cause
When Internal Host Detection is configured on GlobalProtect, during the GP connection Windows first performs a Network Discovery which it sends out both DNS and MDNS queries to verify if the client is in the Internal or External network. It does this by performing a reverse DNS lookup on a private IP configured in the on the GlobalProtect Portal configuration in PAN-OS. Once DNS response with "No such name " we should see DNSQuery 9003, which indicates to the GP client that the end-point is external
Prior to GlobalProtect clients with Windows Update - KB5001330, when the client was connecting from an external network the lookup would fail and return DNSQuery 9003 "No such name ". With Windows clients that installed KB5001330, the DNSQuery is returning 1460 (timeout) which indicates no response was received from the DNS server. This is prompting the GP client to continue querying the DNS Server up to 20 times for a response and resulting in a 60+ second delay in connecting users.
Resolution
Workaround
Option 1
- Disable mDNS on the Windows client
Option 2
- Uninstall Windows Update KB5001330