a4dvqjud9ne31.jpg

Endpoint Security vs. Mobile Access vs. SecuRemote

This is the first and foremost headache you’ll run in to.  Mac only supports Endpoint Security, but Windows clients will have 3 options.   The descriptions aren’t very helpful y as “Enterprise Grade” smells like a marketing term that doesn’t help anyone make a decision.

CheckPointVPNClientWindowsInstall

So here’s a quick breakdown:

  • Checkpoint Endpoint Security requires endpoint security on management server
  • CheckPoint Mobile uses the Mobile access blade and thus licensing
  • SecuRemote does not require a license, but does not support Office Mode

So they key take-away on Endpoint Security VPN vs. Check Point Mobile are fundamentally the same feature-wise, but work on different licensing models.

When to use Office Mode?

The main benefit of Office Mode is it mitigates IP conflict between a user’s home/office network and the VPN domain.  For example, say the user’s workstation is on 192.168.1.0/24 and 192.168.0.0/16 is to be routed via the VPN.  Since the client will simply show up as 10.10.10.100 or whatever for the CheckPoint, this will clash with the topology and the client will be disconnected after a few seconds.

The easy workaround for this problem not using Office Mode is only route very specific internal traffic via the VPN.

VPN Client IP address pool

By default, VPN client IP are controlled by this object:

CP_default_Office_Mode_addresses_pool = 172.16.10.0/24

An automatic NAT rule to hide behind the gateway will be enabled as well, so it’s usually OK to leave this as is.  But, it can be changed at the gateway level under VPN Clients -> Office Mode

Split Tunnel network list

CheckPoint calls this the VPN domain.  By default, it’s generated via the topology, which is a combination of interfaces and routes.  It can instead be manually set on the gateway under Network Management -> VPN Domain.

 

Common VPN Client Problems

Uninstalling Endpoint Security version 81.10 on Windows 10 horks all network adapters

https://community.checkpoint.com/t5/Remote-Access-Solutions/Lost-network-connectivity-uninstalling-Endpoint-VPN/m-p/25650/highlight/false

Workaround is to install/uninstall and older client version such as 80.89

Can’t install client on Windows 10 version 1803

Installation fails with ugly error message “An error occurred during the installation of assembly “Microsoft.VC80.ATL, type=”win32”, version “8.0.50727.42”

CheckPointSecuremoteWindowsInstallFail

This is a known issue that can be caused by an incomplete Microsoft .NET library installation.

Can’t uninstall Mac Client

Simply dragging to the trash won’t fully un-install the client.  Instead, Re-open the .dmg file and Ctrl + click the black and green Uninstaller icon, then Select Open

CheckPointMacVPNClientUninstall

Clients connect to the gateway’s Internal IP address

This is usually because the gateway is behind NAT, referenced by internal IP address in SmartConsole, and Link selection is using the main IP address, which is the default.

The fix is under IPSec VPN -> Link selection.  Put the public IP address as the statically NAT’d IP and the clients will then stay connected to the public IP address.

Clients connect, but can’t access anything, then drop a few second later

In my case this this was due to giving the VPN clients a 10.X.X.X address but having a route to 10.0.0.0/8 via the internal interface, which triggered anti-spoofing rules:

@;2251823;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=1 10.135.200.81:2048 -> 10.135.202.161:33536 dropped by fw_antispoof_log Reason: Address spoofing;
@;2251849;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=17 10.135.200.81:18011 -> 10.135.202.199:18234 dropped by fw_antispoof_log Reason: Address spoofing;
@;2251849;[cpu_0];[fw4_1];fw_log_drop_ex: Packet proto=17 10.135.200.81:18012 -> 10.135.202.199:18234 dropped by fw_antispoof_log Reason: Address spoofing

The simple solution is disable spoofing on the external interface.

An alternate work-around is choose IP address for the VPN clients that are outside the internal interface’s topology.  I used 198.51.100.0/24.  This also fixes the route conflicts described above under “Office Mode”

After initial connection, VPN Client caches gateway’s internal IP address

This will happen when the Checkpoint gateway is behind a NAT.  The fix is provide the external IP address under Gateway -> IPSec VPN -> Link Selection “Always use this address” and enter the external IP in the “Statically NATed IP” field.

Client complains VPN-1 Server could not find any certificate for use for IKE

Means the connection is expecting the client to authenticate via certificate.  Quickest fix: on the gateway under VPN Clients -> Authentication, set the Authentication Method to “Username and password”

Common Gateway/SmartConsole problems not related to VPN

Can’t SSH to gateway after hooking in to SmartConsole

Unlike the Web Admin access, which is implicit, SSH has to be explicitly allowed in the policy.  This is true even when using the dedicated management route feature in R80.30