VPN DNS not resolving

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

VPN DNS not resolving

L1 Bithead

I have users on 3 different local AD domains. We are consolidating, but in the mean time, users have been able to connect to the GlobalProtect VPN and browser network resources. A few weeks ago one user emailed me and said he is connected to VPN, but cannot connect to a terminal server. I check into it and realize that he can ping the IP of the server and connect via the IP address, but DNS is not resolving any names, although the DNS server for the GlobalProtect adpater is set correctly. If i remove the user's computer from the domain, and log into the local account, VPN works perfectly. I am confused how the AD domain would affect the VPN tunnel DNS. Does anyone have any ideas?

7 REPLIES 7

L2 Linker

Sounds like a GP bug. There is a current issue where DNS servers don't update when a network change is detected by the globalprotect client on Windows machines, this issue probably doesn't have anything to do with your AD configuration. Flushing DNS is the current workaround. I'd open up a support case to verify the bug is the same, and to inquire if/when a fix will be released.

 

Weird, we are only seeing it on one client. I am an end user of a share Palo Alto Firewall, so I am not able to open a support ticket. Does downgrading the GP client to an older version work? You mention a workaround, can you elaborate?

We are seeing a similar issue every so often when our users connect to our DFS share via VPN. The DFS share is sometimes unavailable while \\servername resolves immediately. Could this be the same issue?

GlobalProtect Client 3.1.1-27

Hi,

 

We were having the exact same issue, when our users changed from default VPN to a 2 factor authenticated one, the DNS servers would change.

 

The change of the DNS server will cause Windows to invalidate all cached DNS entries, and it will not try to resolve them again until the invalidated cache entry has been purged.

 

Our solution was to use the same DNS server for all VPN gateways.

L1 Bithead

Did you ever find a fix for this?

We're running version 3.1.1 on the client in hopes to resolve this, but nothing so far besides manually running an ipconfig /flushdns script.

We never did. I ended up moving the user to a new computer with a matching domain as the VPN client and that fixed the issue. Not sure why it stopped working or what the issue was, but we found a workaround.

I've seen this type of behavior in multiple windows domain systems.  The issue there was with how windows handles the "short" names for resolution.

 

First is adding the computer local domain

Next is cycling through the domain suffix options on the workstation

 

The fix was two fold.

 

All DNS servers in each domain had forwarders configured to point to all the other internal domain names.  This way no matter what domain the computer belonged to and used for DNS the forwarder would work for the other domain name resolutions.

 

A group policy was then added for computers in each domain to add all the other internal domain names to the DNS suffix list on the computer.  This way they would all be tried for each short name if the local computer domain failed in the lookup.

 

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center
  • 10979 Views
  • 7 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!