Win10 v80.85 endpoint patching VPN connection lost July updates?

[Kevin_Vargo]

Hi - this morning dozens of folks were unable to connect to VPN after powering up their machines; receiving a "Connectivity with the VPN service is lost". 

While  not confirmed, we believe this is due to a Windows patch.  After several hours of troubleshooting we resolved by installing v81.10 but still have no idea what caused this specifically.  I was referred to sk158032, but would really like to know what happened for reference.  If anyone has thoughts on this that'd be great.  All I can say is that I had KB890830 (from June 2019) installed on July 1st and after rebooting (now a week later) I was not able to connect.  Repeatedly I saw the service control manager restarting the CP service.  Below is a snipit of my helpdesk log where I rebooted the PC at 10:24:50 or so.  Thank you.

[10 Jul 9:31:32] Disconnect initiated by user
[10 Jul 9:31:32] Client state is connected
[10 Jul 9:31:33] State connected. User chose to disconnect. Cancelling connection.
[10 Jul 9:31:43] Connect initiated by user
[10 Jul 9:31:43] Client state is idle
[10 Jul 9:31:43] User pressed connect
[10 Jul 9:31:43] Creating primary conn flow to CLUSTER
[10 Jul 9:31:43] Transport is auto detect
[10 Jul 9:31:43] No need to upgrade client, client version is 986008506
[10 Jul 9:31:43] Starting new connection (3)
[10 Jul 9:31:43] Client state is connecting
[10 Jul 9:31:43] Policy changed, restarting connection (3)
[10 Jul 9:31:44] Sent ClientHello
[10 Jul 9:31:44] No need to upgrade client, client version is 986008506
[10 Jul 9:31:44] Starting new connection (3)
[10 Jul 9:31:46] Topology download in progress
[10 Jul 9:31:46] No need to upgrade client, client version is 986008506
[10 Jul 9:31:46] no need executing firewall step
[10 Jul 9:31:46] Office mode IP was set successfully
[10 Jul 9:31:48] OM started successfully with IP = 10.245.74.1.
[10 Jul 9:31:48] Client state is connecting
[10 Jul 9:31:48] Connection was successfully established (3)
[10 Jul 10:22:31] Disconnect initiated by user
[10 Jul 10:22:31] Client state is connected
[10 Jul 10:22:32] State connected. User chose to disconnect. Cancelling connection.
[10 Jul 10:22:49] Console/remote connect has occurred. Ignoring
[10 Jul 10:22:53] Logoff has occurred
[10 Jul 10:22:54] Client state is idle
[10 Jul 10:22:54] Session logoff while idle.
[10 Jul 10:22:54] Client state is idle
[10 Jul 10:22:54] Session logoff while idle.
[10 Jul 10:22:58] Client state is idle
[10 Jul 10:22:58] received system suspend or session lock, state is idle. no action
[10 Jul 10:22:58] Client state is idle
[10 Jul 10:22:58] received system suspend or session lock, state is idle. no action
[10 Jul 10:23:09] Console/remote disconnect has occurred. Disconnecting
[10 Jul 10:23:14] Console/remote disconnect has occurred. Disconnecting
[10 Jul 10:23:14] Console/remote connect has occurred. Ignoring
[10 Jul 10:23:54] Client state is idle
[10 Jul 10:23:54] System resume, state is idle. always connect is on. Connecting
[10 Jul 10:23:54] Always connect scheduled to start in 60 seconds
[10 Jul 10:23:54] Client state is idle
[10 Jul 10:23:54] System resume, state is idle. always connect is on. Connecting
[10 Jul 10:23:54] Always connect scheduled to start in 60 seconds
[10 Jul 10:23:56] Console/remote disconnect has occurred. Disconnecting
[10 Jul 10:23:58] Client state is idle
[10 Jul 10:23:58] Session logoff while idle.
[10 Jul 10:23:58] Client state is idle
[10 Jul 10:23:58] Session logoff while idle.
[10 Jul 10:23:58] Console/remote connect has occurred. Ignoring
[10 Jul 10:24:46] Client state is idle
[10 Jul 10:24:46] received network OUT event while state is idle. no action
[10 Jul 10:26:18] Service was started
[10 Jul 10:26:38] Service was started
[10 Jul 10:26:39] Service was started
[10 Jul 10:26:40] Service was started
[10 Jul 10:26:40] Service was started
[10 Jul 10:26:41] Service was started
[10 Jul 10:26:42] Service was started
[10 Jul 10:26:43] Service was started
[10 Jul 10:26:43] Service was started
[10 Jul 10:26:44] Service was started
[10 Jul 10:26:44] Service was started
[10 Jul 10:26:46] Service was started
[10 Jul 10:26:48] Service was started

ETC......

[Kurtis_Lanovaz]

Hi,

The issue is still under investigation but there is an SK that was created: sk158032 - E80.85 and earlier Remote Access VPN clients service fail to work with "Connectivity with the VPN service is lost" error after latest Windows update (July 10th)

The issue is caused by the client side firewall initialization routine failing.

Trac.log will show the following:

[ 43232 43336][10 Jul 17:49:21][TR_FEATURE_MANAGER] TrFeatureManager::Init: mOfficeModeEnable=true,mSplitDnsEnable=false,mLocationAwarenessEnable=true,mAlwaysConnectEnable=true,mRoamingEnable=true,mHotspotDetectionEnable=true,mFirewallEnable=true,mScvEnable=true
[ 43232 43336][10 Jul 17:49:21][TR_FIREWALL] CFirewallWrapper::InitFirewallMonitor: entering...
[ 43232 43336][10 Jul 17:49:21][TR_FIREWALL] CFirewallWrapper::InitFirewallMonitor: loading library: C:\WINDOWS\system32\FirewallMonitor.dll
[ 43232 43336][10 Jul 17:49:21][TR_FIREWALL] CFirewallWrapper::InitFirewallMonitor: lpFwMonitor_initLibrary returned true
[ 43232 43336][10 Jul 17:49:21][TR_FIREWALL] CFirewallWrapper::InitFirewallMonitor: ERROR - lpFwMonitor_Start failed
[ 43232 43336][10 Jul 17:49:21][TR_FIREWALL] CFirewallWrapper::FreeFirewallMonitor: entering...
[ 43232 43336][10 Jul 17:49:21][TR_FIREWALL] CFirewallWrapper::FreeFirewallMonitor: calling lpFwMonitor_Stop
[ 43232 43336][10 Jul 17:49:21][TR_OVERSITE] critical error: fail to InitFirewallMonitor, going down

[HB_Con]

"Connectivity with the VPN service is lost" error after latest Windows update (July 10th)"

This is inaccurate.  We have experienced the same issue on devices that have not been patched in July.

We even tested this on a vanilla 1809 device with no patches installed at all, and the same issue happened.  Please don't lazily blame this on a patch without proof.

[Dan_Cannon]

E80.85 Released Jul 2018

Windows 10 1809 Released October 2018.

• Always check for compatibility before upgrading Windows OS. Refer to sk115192 - Check Point Endpoint Security Client Support Schedule for New Operating Systems.

Windows 10 1809 supported version is E80.90.

The fact that Check Point have acknowledged an issue in a technically unsupported version should be applauded.

[HB_Con]

We are running 1709 predominantly, 1809 was just used as a vanilla test in one of many attempts to locate the issue.
As it had exactly the same issue as the 1709 using the same version of CheckPoint (80.85) I thought it was a valid test.
So it wasn't CP acknowledging an issue in an unsupported version, it is them doing so on a very much supported version. One of my many tests was just outside of the scope of the version in question.
(Would be nice if I could post a response without a 3 hour delay in approval though!)

[PhoneBoy]

Hi, just to let you know, approval for posts is only required for newer members as an anti-spam measure.
Once users have established themselves, this restriction is removed.
You shouldn't run into this anymore.

[PhoneBoy]

The frequency of Windows updates is the primary reason we issue new versions of the Endpoint Security client on a roughly monthly basis.
This does mean having to upgrade the Endpoint Security client to a more current release when Windows updates are applied.

[HB_Con]

Just to add some more trivia on the subject:

Every device running the affected versions of CheckPoint VPN experienced this issue on the 10th July,  Patch Tuesday patches for July haven't had time to propagate to any devices other than our limited test devices

Devices that were working ok on the 10th, found that a reboot caused the error to happen.  Logging out and back in did not trigger it.  Most of our devices running this VPN software reboot daily.

This puts the issue firmly on the 10th July.

We have tested on vanilla Windows OS installations, older build sequences, uninstalled AV, uninstalled and re-installed CheckPoint, blocked GPOs, removed App Controls, disabled Windows Firewall, installed vanilla CheckPoint E80 (non packaged version).  Nothing worked.

Only "fix" we have is to install E81.  Which we now have to do on all our mobile devices.

In our testing we have ruled out:

• Windows Patching
• Windows 10 OS version (affects 1703, 1709 and 1809)
• AV
• Re-install of E80, both our packaged version and a vanilla downloaded version
• GPOs
• App Controls (Appsense)
• Windows Firewall

This seemingly leaves just the E80 app as the cause of the issue.  Is there a time related kill switch in it?? It seems to be the only thing that would explain why multiple customers are getting the same issue on the same day with no obvious cause.

[Kevin_Vargo]

Well my first sentence was "While  not confirmed, we believe this is due to a Windows patch".  I spent a few hours on this and then reached out to the community stating what I found and looking for advice; not sure how that seems lazy.  I don't think the requirements to pose a question/comment require having proof.  Thanks though.

[HB_Con]

We also spent many hours on this yesterday, and ruled out patching as a cause, as that was our first thought. We did some testing on that supposition though.

However, my quote was not targeted at your initial post, but at the employee response and linked article in that post, both stating the same thing as a cause "Windows patching". WIth no proof, justification or testing. Which is lazy.

[Kevin_Vargo]

ahh, understood.  Thanks for the clarification and additional notes you posted for testing.  Like you, we also only had this issue when restarting the PC.  We tried the "repair" and also disabled AV, it seems completely out of the blue and caught us off-guard to say the least.  We are pushing 81.10 via our gateways to force an upgrade.  It'd be great to understand the cause though.

[Jan_Kleinhans]

We had the same problem and pushing out E80.90 out now via SCCM. We had also issues with Windows 7 Clients and E80.85.