Table Of Contents
Before the VPN can be configured the following features need to be enabled under the gateway properties:
- IPsec VPN: Required for basic RA or L2L VPN
- Policy Server: Required if want to enforce a Desktop server policy on the client (firewall)
- Mobile Access: Required for mobile and SSLVPN
Checkpoint uses IKE over TCP were a full TCP session is opened between the peers for the IKE negotiation during phase1. I think this is used to solves issues relating to fragmented packets, NAT, large UDP packets and port filtering. If it discovers IPsec is blocked it will use visitor mode to tunnel the VPN over 443.
By default Endpoint Security VPN client will use port 443 to negotiate the tunnel, even if Visitor Mode is not selected. The certificate used for this is the CA certificate, however this can be changed by enabling Mobile Access and assigning a certificate to the Mobile Access Portal.
In the logs you will see the initial connection as mobile access, then identity awareness (if enabled) and then VPN for key installation and encrypted traffic.
On the remote machine you need to install the Endpoint Security VPN client. The remote machine will add a route in local routing table for all the ranges specified in the VPN domain with a next hop of the checkpoint within the office mode IP range. Unlike ASAs the checkpoint will show in traceroutes, with the first hop being the tunnel IP your connected to.
- The VPN domain is the remote part of interesting traffic, so what can be reached over VPN
- Local end of the remote access VPN is user groups.
- VPN domain and User groups are linked together in a VPN community
- Office Mode is used to give VPN clients an IP. Need to make sure you also add DNS servers under additional options
- By default not all traffic is routed through the Checkpoint
- Firewall rules need adding to allow the access, add under VPN column
1. Phase1 and Phase2 parameters (RA only) and other global settings
Configure high level properties such as timers, allowed auth methods and P1 & P2 settings.
2. VPN Domain (interesting traffic)
Set the Networks that are within the VPN Domain. The first option is for S2S and the second for the Remote access VPN. Alternatively you can set this in the VPN domain and leave the remote access as the default of same as in Gateway.
3. Global Properties for S2S and RA
Gateway Properties » IPSec VPN. Can edit the certificate store (for clientside auth), define interface used for incoming/ outgoing VPN traffic, routing options, number of tunnels and NAT traversal support.
4. Users, User Templates and Usergroups
- User Template: Define the Expiration, Authentication methods (when not using cert or PSK), location, time and under Encryption can set a pre-shared key (PSK)
- User: Can set all same properties as template but also a certificate. Authentication method checkpoint password is if just want a simple local user account with the password set on the CHeckpoints (not a remote AAA server)
- User Group: Defines which users are allowed access and is referenced in the community
- LDAP Groups: Create a group based on AD users or groups
5. VPN Community
Links the gateways and users together. Can only have ONE remote access community (can have multiple S2S) and participants can be User Groups or LDAP Groups.
6. Global Properties for all VPN clients
Gateway Properties » VPN Clients. Set the VPN client types allowed, certificate used for clientside auth, whether to override user authentication method and Office Mode to assign clients IPs (there is a default CP_default_Office_pool)
Under the remote access menu can configure:
- Hub Mode: Gateway acts as VPN router for the client, all client connections pass through it.
- NAT Traversal: Enable/disable and port number (default port is UDP 2746).
- Visitor Mode: All required VPN connectivity (IKE, IPsec, etc) between the client and the server is tunnelled inside a TCP connection. Think it only uses this if it discovers IPsec is blocked in initial VPN negotiation (IKE over TCP).
7. Firewall rules for access within the VPN tunnel
If you want to use a User group (rather than IP, LDAP group access role) need to right click on the source and Add Legacy User Access. Under VPN select RemoteAccess community.
User authentication with Certificates
The certificate under the IPsec VPN section is only used if you want to authenticate VPN users (like xauth) using certs, it isn’t used during the initial VPN conn to verify the gateway.
To install a new IPsec VPN certificate you must first create a trusted CA for the Certificate Authority that will be issuing the certificate (e.g. Verisign). To create this trusted CA you need the CA certificate from the issuer.
Can now go into gateway properties » IPSec and create a CSR using the trusted CA created. The DN to create the CSR has to be in the following format, although only really need the CN.
Once created click view to get the CSR that can then be give to the certificate authority to sign. Once you receive back the signed certificate from the CA install it clicking complete.
When the VPN client connects to the gateway the updated policy is downloaded to the clients machine and written to the trac.config that is stored in C:\Program Files\CheckPoint\Endpoint Connect.
By default this file is encrypted so to edit it you need to first open the trac.defaults file and on the first Line change the value OBSCURE_FILE INT from 1 to 0. The Checkpoint Endpoint Security VPN service must be restarted for this to take effect.
This file can be repackaged into the initial Endpoint Security VPN client MSI so that custom configuration is already there whenever you install the VPN client on an endusers machines.
The gateways also have a TRAC file that can be used to push configuration down to clients once they connect. This is located on the gateways in the directory $FWDIR/conf/ and called trac_client_1.ttm. Whenever changes are make to the *trac_client_1.ttm_* the security policy needs to be installed on the gateway for it to take effect.
If the TRAC file is identical on all gateways can use the following process to managed the TRAC file on the Security Management Server.
- From the gateway, copy trac_client_1.ttm to the management server.
- Open $FWDIR/conf/fwrl.conf and find the % SEGMENT FILTERLOAD section.
- Add the following line to make the manager copy the TRAC file to the gateways each time a policy is install on the gateways.
NAME = conf/trac_client_1.ttm;DST = conf/trac_client_1.ttm;
- Save the file and install the policy on all gateways.
The following cmd opens the troubleshooting options.
ckp-gw1> vpn tu
********** Select Option ********** (1) List all IKE SAs (2) List all IPsec SAs (3) List all IKE SAs for a given peer (GW) or user (Client) (4) List all IPsec SAs for a given peer (GW) or user (Client) (5) Delete all IPsec SAs for a given peer (GW) (6) Delete all IPsec SAs for a given User (Client) (7) Delete all IPsec+IKE SAs for a given peer (GW) (8) Delete all IPsec+IKE SAs for a given User (Client) (9) Delete all IPsec SAs for ALL peers and users (0) Delete all IPsec+IKE SAs for ALL peers and users
The IPsec SAs can be matched with the packets seen in tcpdump.
1. SPI's related to IKE SA <fe4d87705e0dbf7c,f9e7ce078d954249>: INBOUND: 1. 0x5c003766 OUTBOUND: 1. 0xc7e26cee 17:23:09.010429 IP 10.255.211.3.ipsec-nat-t > host81-139-193-41.in-addr.btopenworld.com.54884: UDP-encap: ESP(spi=0xc7e26cee,seq=0x1760), length 84 17:23:09.027246 IP 10.255.211.3.ipsec-nat-t > host81-139-193-41.in-addr.btopenworld.com.54884: UDP-encap: ESP(spi=0xc7e26cee,seq=0x1761), length 84 17:23:11.026036 IP 10.255.211.3.ipsec-nat-t > host81-139-193-41.in-addr.btopenworld.com.54884: UDP-encap: ESP(spi=0xc7e26cee,seq=0x1762), length 84