- Products
- Learn
- Local User Groups
- Partners
-
More
Join Us for CPX 360
23-24 February 2021
Important certificate update to CloudGuard Controller, CME,
and Azure HA Security Gateways
How to Remediate Endpoint & VPN
Issues (in versions E81.10 or earlier)
IDC Spotlight -
Uplevel The SOC
Important! R80 and R80.10
End Of Support around the corner (May 2021)
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......
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
"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.
E80.85 Released Jul 2018
Windows 10 1809 Released October 2018.
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.
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:
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.
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.
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.
About CheckMates
Learn Check Point
Advanced Learning
WELCOME TO THE FUTURE OF CYBER SECURITY