VPN DNS not resolving

[newfrenchbakery]

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?

[MangoTango]

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.

[newfrenchbakery]

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?

[Indorama_Ventures]

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

[as-mg]

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.

[policeman51]

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.

[newfrenchbakery]

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.

[pulukas]

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.