CheckPoint Initial Configuration via CLI

The default credentials are admin/admin

Verify the management interface

show management interface

Set the management interface with IP address 192.168.1.222/255.255.255.0

set interface Mgmt ipv4-address 192.168.1.222 mask-length 24

Verify IP address for management interface

show interface Mgmt ipv4-address

Ping something

ping 192.168.1.1

Set the default route to 192.168.1.1

set static-route default nexthop gateway address 192.168.1.1 priority 1 on

Create internal route for 10.0.0.0/8 via gateway 10.10.10.10

set static-route 10.0.0.0/8 nexthop gateway address 10.10.10.1 on

Verify routing

show route

Set DNS servers

set dns primary 8.8.8.8
set dns secondary 9.9.9.9

Save the configuration

save config

Show all interface

show interfaces

Show interfaces with IP addresses configured

show security-gateway monitored-interfaces

Create an 802.3ad (LACP) bonded logical interface with eth1 & eth2 as physical members

add bonding group 1
set bonding group 1 mode 8023AD
set bonding group 1 lacp-rate fast
add bonding group 1 interface eth1
add bonding group 1 interface eth2

Create a VLAN sub-interface on bond1 with 802.1q tag 123

add interface bond1 vlan 123

Check software version

show version all

Get hardware information and serial number

show asset system

Change admin password

set user admin password

Set expert mode password

set expert-password

Check policy Status

fw stat

Clear the current local policy

fw unloadlocal

Check site-to-site VPN status

vpn tu tlist

Reset VPN tunnels (list/delete IKE/IPSec SAs)

vpn tu

Modify license, configure SNMP, reset SIC connection:

cpconfig

Verify number of CPUs

fw ctl multik stat

View CPU to connection distribution table

fw ctl affinity -l -r

Reboot the firewall

reboot

Advertisement

IPSec VPN Spoke Router using FQDN authentication

In a previous post I’d covered doing site-to-site IPSec tunnels on Cisco routers when one or both devices are behind NAT.  But what if multiple spoke routers have dynamic IP addresses? Or how about many behind the same NAT address? 

The solution is to have the spoke routers authenticate using FQDN hostname rather than IP address.  I’ve seen lots of examples which overly complicate how to do this.  It’s actually pretty simple and only requires minor changes.  Let’s assume the spoke routers have dynamic IPs and the hub has a static IP of 203.0.113.222…

IKEv1

Spoke Router

On spoke routers with IKEv1, simply replace  the “crypto keyring” statement with “crypto isakmp peer” to use FQDN authentication and IKE aggressive mode, like this:

hostname spoke1
! 
no crypto keyring MyHub
crypto isakmp peer address 203.0.113.222 [vrf InternetVRFName]
 set aggressive-mode password XXXXXXXX
 set aggressive-mode client-endpoint fqdn spoke1.mydomain.com 
!

Note the fqdn hostname doesn’t necessarily need to match the router’s hostname

IKEv2

Spoke Router

Set the Hub’s IP address and pre-shared key in an IKEv2 keyring:

crypto ikev2 keyring MY_IKEV2_KEYRING
 peer MyHub
  address 203.0.113.222
  pre-shared-key MySecretKey1234    ! Must be 16 chars or longer

The identity (hostname) in the IKEv2 profile via the identity local line:

hostname spoke1
!
crypto ikev2 profile SPOKE_IKEV2_PROFILE
 match address local interface GigabitEthernet0/0
 match identity remote address 203.0.113.222 255.255.255.255
 identity local fqdn spoke1.spokedomain.com
 authentication remote pre-share
 authentication local pre-share
 keyring local MY_IKEV2_KEYRING
 dpd 20 2 periodic 
!

IPSec profile:

crypto ipsec profile SPOKE_IPSEC_PROFILE
 set security-association lifetime kilobytes disable
 set pfs group14
 set ikev2-profile SPOKE_IKEV2_PROFILE
!

Tunnel Interface and static route to 10.0.0.0/8:

interface Tunnel1
 ip address 169.254.1.100 255.255.255.0
 ip tcp adjust-mss 1379
 keepalive 10 3
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 203.0.113.222
 tunnel protection ipsec profile SPOKE_IPSEC_PROFILE
!
ip route 10.0.0.0 255.0.0.0 Tunnel1

Hub Router

Each Spoke will need an entry. Use identity in the entry, not hostname

crypto ikev2 keyring SPOKES_IKEV2_KEYRING
 peer spoke1
  identity fqdn spoke1.spokedomain.com
  pre-shared-key MySecretKey1234
 !

The IKEv2 profile will be a bit different. The domain is used to match multiple spokes:

crypto ikev2 profile HUB_IKEV2_PROFILE
 match address local interface GigabitEthernet0/0
 match identity remote fqdn domain spokedomain.com
 identity local fqdn myhub.hubdomain.com
 authentication remote pre-share
 authentication local pre-share
 keyring local SPOKES_IKEV2_KEYRING
 dpd 10 2 on-demand
 virtual-template 1

The IPSec profile is almost the same but is responder-only (passive):

crypto ipsec profile HUB_IPSEC_PROFILE
 set security-association lifetime kilobytes disable
 set pfs group14
 set ikev2-profile HUB_IKEV2_PROFILE
 responder-only

Rather than a regular tunnel interface, a virtual template one is used:

interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination dynamic
 tunnel protection ipsec profile HUB_IPSEC_PROFILE

CheckPoint Remote Access VPN Caveats

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