Globalprotect vpn disconnects few times a day

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

Globalprotect vpn disconnects few times a day

L1 Bithead

Hi Guys,


Users are logged out of vpn few times a day and reconnected back in Milliseconds. Below is the log which shows error 10052



(T1636)Debug( 278): 02/01/21 07:54:52:256 IPSec tunnel receive failed with error 10052(The connection has been broken due to keep-alive activity detecting a failure while the operation was in progress.)
(T1636)Error(1357): 02/01/21 07:54:52:257 VPN: Socket Failed to receive! ret = -1
(T1636)Info (1944): 02/01/21 07:54:52:257 ProcPackets, RecvFromSocket() failed
(T1636)Info ( 567): 02/01/21 07:54:52:257 ProcPackets failed, get out of ProcMonitor
(T1636)Debug( 626): 02/01/21 07:54:52:257 Tunnel downtime is 78 miliseconds
(T1636)Debug(5579): 02/01/21 07:54:52:257 Show Gateway Checking network availability and restoring VPN connection when network is available.
(T1636)Debug(6645): 02/01/21 07:54:52:257 --Set state to Restoring VPN Connection
(T7676)Debug(2381): 02/01/21 07:54:52:257 Setting debug level to 5
(T1636)Debug( 662): 02/01/21 07:54:52:258 Stop ProcDrv before disconnect
(T1832)Info ( 951): 02/01/21 07:54:52:258 ProDrv: VPN disconnect event, get out of ProcDrv
(T1832)Info ( 980): 02/01/21 07:54:52:258 ProcDrv thread dies
(T1636)Info ( 914): 02/01/21 07:54:52:258 ProcDrv quit
(T1636)Debug( 667): 02/01/21 07:54:52:258 Stop ProcTunnel before disconnect
(T3592)Info (1031): 02/01/21 07:54:52:258 ProTunnel: VPN disconnect event, get out of ProcTunnel
(T3592)Info (1047): 02/01/21 07:54:52:258 ProcTunnel thread dies
(T1636)Info ( 995): 02/01/21 07:54:52:258 ProcTunnel quit
(T1636)Debug( 229): 02/01/21 07:54:52:259 IPSec anti-replay statistics: outside window count 0, replay count 0
(T1636)Debug( 231): 02/01/21 07:54:52:259 Disconnect udp socket
(T1636)Debug( 547): 02/01/21 07:54:52:259 unset network
(T1636)Debug(2722): 02/01/21 07:54:52:259 UnsetRoutes(): RestoreDefaultRoutes.
(T1636)Debug(2728): 02/01/21 07:54:52:259 Unset 3 routes
(T1636)Debug(2748): 02/01/21 07:54:52:259 UnsetRoutes: DeleteIpForwardEntry[0] (
(T1636)Debug(2748): 02/01/21 07:54:52:259 UnsetRoutes: DeleteIpForwardEntry[1] (
(T1636)Debug(2748): 02/01/21 07:54:52:259 UnsetRoutes: DeleteIpForwardEntry[2] (
(T1636)Debug(6452): 02/01/21 07:54:52:259 UnsetGatewayRoutes: DeleteIpForwardEntry(
(T1636)Info (4952): 02/01/21 07:54:52:259 RemoveGatewayInRouteTable(vnicIdx=21)
(T1636)Info (5000): 02/01/21 07:54:52:259 delete 1 ip forward entry:
(T1636)Info (5000): 02/01/21 07:54:52:259 delete 2 ip forward entry:
(T1636)Info (5000): 02/01/21 07:54:52:259 delete 3 ip forward entry:
(T1636)Info (5000): 02/01/21 07:54:52:259 delete 4 ip forward entry:
(T1636)Info (5000): 02/01/21 07:54:52:259 delete 5 ip forward entry:
(T1636)Debug(2687): 02/01/21 07:54:52:259 UnsetRoutesV6: No route installed before
(T1636)Debug(1408): 02/01/21 07:54:52:259 Disconnect virtual interface
(T13376)Debug(6197): 02/01/21 07:54:52:672 NetworkConnectionMonitorThread: route change detected. Wait for 3 seconds.
(T13376)Debug(5025): 02/01/21 07:54:52:672 No need to check gateway route since no tunnel.
(T1636)Debug( 25): 02/01/21 07:54:52:733 create thread 0x69c with thread ID 2880
(T1636)Debug(1424): 02/01/21 07:54:52:733 Start FlushDNSCache thread 0x69c
(T2880)Debug(2223): 02/01/21 07:54:52:740 FlushDNSCache thread: run cmd: cmd /C ipconfig /flushdns > "C:\Program Files\Palo Alto Networks\GlobalProtect\4"
(T9060)Debug( 530): 02/01/21 07:54:52:743 ST,exit reader set!!!!(T9060)Debug(3062): 02/01/21 07:54:52:743 ST,End gp filter reader
(T1636)Debug(2442): 02/01/21 07:54:52:831 ST,service status is 00000004
(T1636)Debug(2447): 02/01/21 07:54:52:831 ST,service already started
(T1636)Debug(2450): 02/01/21 07:54:52:886 ST,Service stop send, current status = 00000001.
(T1636)Debug(1195): 02/01/21 07:54:52:886 SPStop is called
(T1636)Debug( 848): 02/01/21 07:54:52:954 restorednssuffix: dnsSuffix:fsource.local
(T7676)Debug(2381): 02/01/21 07:54:52:970 Setting debug level to 5
(T13376)Debug(6258): 02/01/21 07:54:55:708 NetworkConnectionMonitorThread: m_state = 0, m_bOnDemand=1, m_bAgentEnabled=1, m_bJustResumed is 0,
m_bHibernate is 0, m_bAgentEnabled is 1, m_bDisconnect is 0, IsConnected() is 0, IsVPNInRetry() is 1.
(T13376)Debug(5025): 02/01/21 07:54:55:708 No need to check gateway route since no tunnel.
(T13376)Debug(6266): 02/01/21 07:54:55:708 Set retry network check event in retry mode
(T13376)Debug(6278): 02/01/21 07:54:55:708 NetworkConnectionMonitorThread: Detected route change, but skip network discovery.
(T1636)Error(5310): 02/01/21 07:54:56:358 DLSA, wait time out for monitor route change thread, time out = 3 seconds
(T1636)Error(1821): 02/01/21 07:54:56:358 DLSA, route changing monitor thread leaked
(T1636)Debug(5982): 02/01/21 07:54:56:358 DLSA, savedMetric1Routes not present, do not need to restore
(T1636)Debug(5347): 02/01/21 07:54:56:358 Proxy is not disabled before, no need to restore
(T1636)Debug( 839): 02/01/21 07:54:56:380 PreviousDNSInfo doesn't exist, no need to restore
(T1636)Debug(1874): 02/01/21 07:54:56:389 UnsetDNSSuffixSearchOrder returns 0
(T1636)Debug(10848): 02/01/21 07:54:56:392 SetVpnStatus called with new status=0, Previous Status=1
(T1636)Debug(4124): 02/01/21 07:54:56:392 UpdatePrelogonStateForSSO() - User-logon tunnel state = Disconnected


This is most commonly caused by an intermittent wireless (wifi) connection. If you are using a wireless network that either has a weak signal or has a lot of other devices connected to it, your connection may drop for a few seconds causing GlobalProtect to reconnect. access code

L0 Member

I would have actually suggested the opposite to palogeek. Forcing to IPsec rather than SSL has solved a similar issue I've seen in the past that started when the number of remote VPN users increased significantly. Panorama Charter

Some disconnect issues have been fixed:

A hotfix for 5.2.5 has been released with a lot of fixes btw: Addressed Issues in GlobalProtect App 5.2 (

L1 Bithead

There are most likely intermittent network issues.
In my case there was a loop at the ISP network which lead to packets reaching their TTL value.

The tunnel drops happened around the same time when the client received an "ICMP time-to-live exceeded" packet.

I recommend looking on the wire (i.e. with wireshark) on the physical interface (not the virtual GP adapter). 

As a quick workaround you could block incoming ICMP TTL exceeded packets either on the router level or local firewall or increase the IP TTL value in the registry (Windows 10 defaults to 128) should the packet capture reveal that this is actually the case.

L0 Member

Apart from the segregation of roles and duties, the portal is also used to discuss the upcoming programs. Only the Panorama charter employees and supervisors are authenticated to log in to the portal, and no outside party can enter it. 

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!