- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
06-22-2016 03:37 AM - edited 06-22-2016 03:37 AM
Hi,
I'm having a single client, running Windows 10 Pro, that we're having issues with.
When the user connects to their network at home, they are unable to connect to VPN, and it seems like the issues is caused by GlobalProtect setting the WiFi adapter's DNS-address to that of the VPN proxy DNS.
I have tried against mobile hotspots, and the same issue is present here as well - I change the WiFi to use DNS obtained by DHCP, and it changes to VPN DNS as soon as it's connected once.
Have anyone else encountered issues like this recently?
06-22-2016 07:40 AM
Do you have the setting flush dns set? Now they have this setting available on the application page (assuming you have 7.1.x firewalls now). Make sure you turn it off.
I set this via the registry in the past and it created this exact problem on the v2.x GP clients and presumably still exists in v3
its a horrible design and have reported it multiple times. Once I figured it out that it was that setting, I disabled it and never used it again. I flush the DNS using a script on connect now, doing Palo Alto's job.
Never should a VPN client ever ever ever change settings on any adapter other than their own. No other VPN client does for a good reason. This was presumably their band aid fix for "DNS queries" to make sure both adapters use the same DNS. sorry, but that is not how it works and horrible software programming when others do not have to do that. Also, who would have thought that setting Flush DNS would change DNS settings on the wifi adapter? seriously? Palo Alto TAC told me to set the registry key and never told me it would do that for the network adapter, since I wanted the DNS to be flushed like any other VPN client does properly. Self inflicted painful months. By the way, it is not just the wifi adapter, it will do it for the ethernet adapter as well, but most people use wifi anyhow.
It has caused my company grief with users remotely not able to access internet or connect, because its stuck on DNS settings intended for when you are inside the network.
06-22-2016 04:07 AM
Hey mate,
I have a similar issue with GP 3.0.2 and 7.1.2 on a WIN7.
DNS settings of the Wireless card are changed once the VPN is connected.
It should be set to the PANGP virtual adapter and not the Wireless card if i m correct.
After the disconnection, original settings are not set back. Need to manually reconfigure them.
JB
06-22-2016 04:11 AM
These versions matches the one in our scenario, so this sounds like a bug.
Hopefully someone from PAN will notice and either post a workaround or resolve the issue in an upcoming version of either GP or PANOS.
06-22-2016 04:40 AM
I opened a case to the Palo TAC. We'll see..
06-22-2016 04:42 AM - edited 06-22-2016 04:43 AM
Log files.
IP's:
(T5632) 06/22/16 10:06:29:098 Debug(1119): save old dns: Wi-Fi--dhcp=1,10.20.30.1, flags=0x000001c5, use dynamic dns = 1 (T5632) 06/22/16 10:06:29:098 Debug( 785): SaveStringToPreviousSetting, str0=Wi-Fi, nStr=1 (T5632) 06/22/16 10:06:29:098 Debug( 787): str0=dhcp=1,10.20.30.1 (T5632) 06/22/16 10:06:29:098 Debug( 865): re-read previousDNSInfo return 0, dwSize=49 (T5632) 06/22/16 10:06:29:098 Debug( 867): write success nRetry=0, flush it now (T3528) 06/22/16 10:06:29:098 Info (1940): Setting debug level to 5 (T5632) 06/22/16 10:06:29:098 Debug( 875): flush key, ret = 00000000 (T5632) 06/22/16 10:06:29:098 Debug(1137): run cmd: cmd /C netsh interface ip set dns "Wi-Fi" static 192.168.50.1 validate=no > "C:\Program Files\Palo Alto Networks\GlobalProtect\tmp.txt" (T5632) 06/22/16 10:06:29:161 Debug( 95): (T5632) 06/22/16 10:06:29:161 Debug(1143): run cmd to verify previous command: cmd /C netsh interface ip show dns "Wi-Fi" > "C:\Program Files\Palo Alto Networks\GlobalProtect\tmp.txt" (T5632) 06/22/16 10:06:29:223 Debug( 95): (T5632) 06/22/16 10:06:29:223 Debug( 95): Configuration for interface "Wi-Fi" (T5632) 06/22/16 10:06:29:223 Debug( 95): Statically Configured DNS Servers: 192.168.50.1 (T5632) 06/22/16 10:06:29:223 Debug( 95): Register with which suffix: Primary only (T5632) 06/22/16 10:06:29:223 Debug( 95): (T5632) 06/22/16 10:06:29:223 Debug(1150): verify success!
-------------------------------------------
(T5632) 06/22/16 10:07:01:950 Info (1680): Disconnect() called (T5632) 06/22/16 10:07:01:950 Debug( 437): vpn disconnect (T5632) 06/22/16 10:07:01:950 Debug( 438): Delete m_vpn in CControlManager::DisconnectVPN() (T6720) 06/22/16 10:07:01:950 Info ( 375): PktProcess: VPN disconnect event, get out of ProcMonitor (T6724) 06/22/16 10:07:01:950 Info ( 535): ProDrv: VPN disconnect event, get out of ProcDrv (T6724) 06/22/16 10:07:01:950 Info ( 552): ProcDrv thread dies (T6720) 06/22/16 10:07:01:950 Info ( 509): ProcDrv quit (T6720) 06/22/16 10:07:01:950 Info ( 495): ProcMonitor thread dies (T5632) 06/22/16 10:07:01:950 Debug( 221): do_disconnect is called in VPN stop (T5632) 06/22/16 10:07:01:950 Debug( 218): Disconnect udp socket (T5632) 06/22/16 10:07:04:763 Debug( 322): unset network (T5632) 06/22/16 10:07:04:763 Debug(2067): UnsetRoutes(): RestoreDefaultRoutes. (T5632) 06/22/16 10:07:04:763 Debug(2073): Unset 2 routes (T5632) 06/22/16 10:07:04:763 Debug(2092): UnsetRoutes: DeleteIpForwardEntry[0] (0.0.0.0) (T5632) 06/22/16 10:07:04:763 Debug(2092): UnsetRoutes: DeleteIpForwardEntry[1] (192.168.50.1) (T5632) 06/22/16 10:07:04:763 Debug(2110): UnsetRoutes: DeleteIpForwardEntry(150.150.150.150) (T5632) 06/22/16 10:07:04:763 Info (3054): RemoveGatewayInRouteTable(vnicIdx=17) (T5632) 06/22/16 10:07:04:763 Debug( 629): FlushDNS, string 0 is --GPDNS--:192.168.50.1 (T5632) 06/22/16 10:07:04:763 Debug( 629): FlushDNS, string 1 is Wi-Fi:dhcp=1,10.20.30.1 (T5632) 06/22/16 10:07:04:763 Debug( 629): FlushDNS, string 2 is dnsSuffix:domain.com (T5632) 06/22/16 10:07:04:763 Debug( 644): pGPDNS is --GPDNS--:192.168.50.1 (T5632) 06/22/16 10:07:04:810 Debug( 95): (T5632) 06/22/16 10:07:04:810 Debug( 95): Configuration for interface "Wi-Fi" (T5632) 06/22/16 10:07:04:810 Debug( 95): DNS servers configured through DHCP: 192.168.10.10 (T5632) 06/22/16 10:07:04:810 Debug( 95): 192.168.10.15 (T5632) 06/22/16 10:07:04:810 Debug( 95): Register with which suffix: Primary only (T5632) 06/22/16 10:07:04:810 Debug( 95): (T5632) 06/22/16 10:07:04:810 Debug( 533): FlushDNS, GPDNS information set but the current connection does not has it, return now (T5632) 06/22/16 10:07:04:810 Debug( 594): ret=0 (T3528) 06/22/16 10:07:04:810 Info (1940): Setting debug level to 5 (T5632) 06/22/16 10:07:04:810 Debug( 771): RestoreDNSSetting, return is -1 (T5632) 06/22/16 10:07:04:810 Debug(3895): DLSA, savedMetric1Routes not present, do not need to restore (T5632) 06/22/16 10:07:04:810 Debug(3383): DLSA, RestoreProxySetting now (T5632) 06/22/16 10:07:04:810 Debug(3400): ProxyDisabledByMe is false or not present, leave RestoreProxySetting now (T5632) 06/22/16 10:07:04:825 Debug( 620): PreviousDNSInfo not exit, do not need to restore, ret=00000002 (T5632) 06/22/16 10:07:04:825 Debug( 486): remove dns setting failed with ret = 00000002 (T5632) 06/22/16 10:07:04:825 Debug(1842): UnsetDNSSuffixSearchOrder returns 0 (T5632) 06/22/16 10:07:04:841 Debug(1847): UnsetDNSServerSearchOrder returns 0 (T5632) 06/22/16 10:07:04:872 Debug(1849): UnsetWINSServer returns 68 (T5632) 06/22/16 10:07:04:872 Debug( 224): unsetnetwork is called in vpn stop (T5632) 06/22/16 10:07:04:872 Debug( 322): unset network
06-22-2016 07:40 AM
Do you have the setting flush dns set? Now they have this setting available on the application page (assuming you have 7.1.x firewalls now). Make sure you turn it off.
I set this via the registry in the past and it created this exact problem on the v2.x GP clients and presumably still exists in v3
its a horrible design and have reported it multiple times. Once I figured it out that it was that setting, I disabled it and never used it again. I flush the DNS using a script on connect now, doing Palo Alto's job.
Never should a VPN client ever ever ever change settings on any adapter other than their own. No other VPN client does for a good reason. This was presumably their band aid fix for "DNS queries" to make sure both adapters use the same DNS. sorry, but that is not how it works and horrible software programming when others do not have to do that. Also, who would have thought that setting Flush DNS would change DNS settings on the wifi adapter? seriously? Palo Alto TAC told me to set the registry key and never told me it would do that for the network adapter, since I wanted the DNS to be flushed like any other VPN client does properly. Self inflicted painful months. By the way, it is not just the wifi adapter, it will do it for the ethernet adapter as well, but most people use wifi anyhow.
It has caused my company grief with users remotely not able to access internet or connect, because its stuck on DNS settings intended for when you are inside the network.
06-22-2016 07:43 AM
yep, just noticed your logs and reviewed. you do indeed have flush dns enabled.
also be prepared to have to uninstall the GlobalProtect client and reinstall it, to clear out that bad setting. that was unfortunately my fix for the issue, because even though if it was disabled, it somehow was still cached and continued to do it until I uninstalled it and reinstalled.
Hopefully thats better in v3.0.2 and 7.1.x code. When I was going with this problem, I was on v2.3.x GP and 7.0.x
06-23-2016 03:37 AM
This was my prime suspect as well.
You mention that you are currently running a script at VPN logon, is there any way to automate this in GlobalProtect?
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!