DNS lookup takes a long time with GP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

DNS lookup takes a long time with GP

L1 Bithead

GlobalProtect Gateway is being used, and all traffic is being routed to the firewall except for some network.

 

DNS lookup takes a long time when I input the domain (website which not in the PC DNS table) that the browser accesses first while connected to a VPN

- DNS Lookup time takes about 5-10 seconds

 

The DNS server is using an internal server, and the network is belong to split tunneling exceptions.

 

I am wondering why DNS lookup processing is delayed.

Or is it correct that DNS lookup takes a long time during VPN connection?

1 accepted solution

Accepted Solutions

L1 Bithead

The issue was resolved as follows.

 

Cause: Querying queries to all NICs that have DNS Lookup enabled, so lookup time increases while waiting for results from VPN NIC

 

Resolution: Register in paloalto registry to run batch script after VPN authentication.
The script content deletes the DNS Server settings of the VPN NIC to set DNS queries to use only the primary NIC of the PC.

View solution in original post

12 REPLIES 12

L7 Applicator

Do you also have GP app setting to split tunnel DNS and what GP client version are you using?

GP Client version is 5.2.6-87(latest)

And Split-Tunnel Option is "Both Network Traffic and DNS" from GP-Portal-Agent-Config-App

Try removing that setting from the agent to see if that is the issue.

are you testing with a dns lookup tool/app or in the browser itself.

That option was initially "Network Traffic Only", but DNS Lookup took a long time, so I switched to "Both Network Traffic and DNS".

The test is being done on my PC, and the DNS cache table is checked with the "ipconfig /displaydns" command.

are you adding the url in nslookup or just adding it in the browser

I do not add additional URL.

 

For my case, the DNS server belongs to the split tunneling exception, so the dns server is left blank in the gateway-agent-network service configuration.
So DNS uses PC's default DNS settings.

This does not happen when i do the same.

 

I have 1 domain in "Domain Split Tunnel" and have left my DNS servers blank in the gateway services and have set both network and DNS in portal app.

 

as soon as i browse to the website that is in my split tunnel it resolves instantly with my local DNS.

L7 Applicator

MickBall_0-1619082909059.jpeg

 

MickBall_1-1619083254881.png

 

L1 Bithead

As you said, I call the internal DNS server and get the IP right away.


However, the browser notificate that the host is being searched, and the DNS lookup time is very long.

Looking through wireshark during this time, vpc nic are not communicating with the target website.

 

The chrome/edge browser issue are the same. It doesn't appear to be a browser issue.

 

In summary

1. vpn connect

2. connect to website domain from browser, connect to internal DNS server from pc default nic

3. get IP from internal DNS server (There seems to be no problem so far.)

4. (vpn nic) The browser is looking for the host, and this is taking a long time.

L7 Applicator

If you are using wireshark then what happens to the packet captures when the DNS replies in summary 3.  does it pause or do you see connection attempts to the correct address.

1.png

This packet is a capture of DNS query with nslookup command on PC's origin NIC(not VPN NIC).

The first second query is the result of a query against the DNS suffix, and the last is the correct query result.

 

Further confirmation

The VPN NIC also sends query packets to the internal DNS.
(Packets come into the Paloalto firewall. It doesn't seem to apply to the split-tunneling exception.)

 

Information
1. Not all queries are requested, but only a few packets request duplicate DNS queries using Origin NICs and VPN NICs.
2. Packets requested by the VPN NIC only have a request and no response.
3. If the DNS lookup in the web browser takes a long time and the web page is displayed normally, the query packet is only sent to the PC NIC, and the packet is not generated from the VPN NIC.

It seems to be because the DNS query is being called concurrently with the PC NIC and VPN NIC.

 

 

 

L1 Bithead

The issue was resolved as follows.

 

Cause: Querying queries to all NICs that have DNS Lookup enabled, so lookup time increases while waiting for results from VPN NIC

 

Resolution: Register in paloalto registry to run batch script after VPN authentication.
The script content deletes the DNS Server settings of the VPN NIC to set DNS queries to use only the primary NIC of the PC.

  • 1 accepted solution
  • 9107 Views
  • 12 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!