GlobalProtect has DNS issues after waking from sleep mode

[jrauman]

GlobalProtect on Windows.  User locks computer and computer goes to sleep. They return and unlock.   If GlobalProtect has disconnected while in sleep mode, they user reconnects succsfully.  User's drive mapping fail and apps fail.  Pings name of server and that fails.  PIngs IP address of server succeeds.  Restarts PC and everything is fine again.

Whats going on?

[Mick_Ball]

What version of client do you have.  When device wakes from sleep mode or switches from lan to wifi the client tries to reconnect to the previous gateway and some routing/domain issues seem to take place.

the same issue applies when using domain split tunnel exclusions.

have you tried a GP refresh before a reboot, are you above V5.1.

[HoomanF]

We have 5.2.9 , we have tried GP refresh connection, it sometimes fixes the issue but ideally we want the GP to restore connection after sleep without user having to refresh/reboot.

What is the fix for the issue you mentioned? 

"

---

@Mick_Ball wrote:

 When device wakes from sleep mode or switches from lan to wifi the client tries to reconnect to the previous gateway and some routing/domain issues seem to take place.

the same issue applies when using domain split tunnel exclusions.

[BPry]

@HoomanF,

You shouldn't be running into any issues with 5.2.9. I would recommend that you look at your client logs on an endpoint and see if they give you any clear errors in addition to checking your traffic logs and see if you have any traffic being received by the firewall. 

[mlinsemier]

I am running into identical issues with GP client versions 5.2.8 - 5.2.10 and the latest 6.0.  It seems to be DNS related as it also shows that we are running from a "cached profile" where before it would show portal gateways as "connected".  We haven't changed our configurations in regards to pre-login and always-on for at least a year and a half and we have double and triple checked our configs (we have a ticket open with TAC on this now), we have split tunneled the portal/gateway IP addresses and domains), and just noticed the reconnect and portal cache issues recently (last 3-4 months).

If anyone found a fix for this please share.

[EfrainMorales]

We are having a ton of complaints about this same issue, but not sure if that's something related to the computer or the app itself. If someone has a fix on this, would be appreciated. I have the same issues as Minsemier explained.

[mlinsemier]

Is your Pre-Logon Tunnel Rename Timeout set to -1 or something different?  We noticed that we can successfully reach the GlobalProtect portal perfectly when this is set to 0 which is not a graceful switch from pre-logon to user logon.  Setting this back to -1 immediately re-introduces the "Cached Profile Config" issue.  Additionally, we also have the issue where waking up from sleep the machine will not reconnect until a reboot.  

I do have a TAC case open with Palo Alto but I am getting a bit of a runaround there trying to get to someone that truly understands GP.

[EfrainMorales]

Hi Mlinsemier,

Thanks for your response.

Yep, Pre-Logon Tunnel Rename Timeout is set as default with - 1 and the User Switch Tunnel Rename Timeout is set as 0, We have users under Windows and Mac, but the users with MAC computers mostly are facing this issue. They can reproduce the issue when they are just closing the lid at the end of the shift, but once they are turning it on again, GP is spinning only.

[ChristerJohanss]

Hi everyone,
Have someone experienced this problem with GP and laptops waking up from "sleep"?? I'm running 6.1.1 and I suspect that the problem is still there. It's supposed to have been fixed in 6.0.1 (GPC-13774).

[ShajadAshraf]

Hello, issue looks similar to described above by @ChristerJohanss .  Happens with either GP 6.1.1 or 5.2.12 and found that the issue happens when the pc changes it's powersettings - see extract from GPS Log of one affected user (who tried to access VPN resource at 13:50).  The DNS resolution doesn't work but IP does..

(P5704-T17928)Debug( 917): 05/23/23 13:25:09:011 HandleDnsCallback: failed to parse dns req packet.
**(P5704-T5708)Info ( 397): 05/23/23 13:30:44:938 Received powersetting change event
*(P5704-T5708)Debug(15418): 05/23/23 13:30:44:938 Wakeup from modern standby
(P5704-T5708)Debug( 348): 05/23/23 13:30:49:102 Received session change, event type 8, session 1
(P5704-T5708)Info ( 428): 05/23/23 13:49:32:647 Received power event, type 0x0000000a
(P5704-T8648)Info ( 531): 05/23/23 13:49:32:855 msgtype = sleep
(P5704-T8648)Info (2079): 05/23/23 13:49:32:855 ProcessServerSleep called
(P5704-T8648)Debug( 198): 05/23/23 13:49:32:855 Now is 17280640. CheckHipTimeoutAfterSleep: 2615000 ms
(P5704-T8648)Debug(2103): 05/23/23 13:49:32:855 Out-of-sleep not during network discovery.
(P5704-T8648)Debug(2147): 05/23/23 13:49:32:855 State is Connected
(P5704-T8648)Debug(1898): 05/23/23 13:49:32:855 Send response to client for request sleep
(P5704-T8648)Info ( 531): 05/23/23 13:49:33:878 msgtype = sleep
(P5704-T8648)Info (2079): 05/23/23 13:49:33:878 ProcessServerSleep called
(P5704-T8648)Debug(2086): 05/23/23 13:49:33:878 Received wakeup event already. ignore this one

So issue from the original post continues...

[YordanYordanov]

hi

has anyone found a solution? 

[ShajadAshraf]

Hello Yordan,

We were advised to try this key which looks to be having a positive impact - please test in your environment first before deployment.

[HKEY_LOCAL_MACHINE\SOFTWARE\Palo Alto Networks\GlobalProtect\Settings]
"DNSBlockMethod"=dword:00000002

Regards,

Sarge

[YordanYordanov]

hi Sarge

thx for the Suggestion, i will try and let you know. Do you know when the software will be fixed?

br

Yordan

[YordanYordanov]

hi Sarge,

Unfortunately, this does not help, the problem is still there. we use GP 6.2.0 and the problem was not solved as anonced in PA :

GlobalProtect App 5.2.11 Addressed Issues

GPC-13774 Fixed an issue where the GlobalProtect tunnel could not send traffic after the system woke up from sleep mode.

Any suggestions?

regards

Yordan

[MikeAkam]

This also didn't work for us. Have we got a fix for this yet?