Site-to-Site IPsec VPNs in Check Point Firewall

A Virtual Private Network (VPN) is a secure-connectivity platform that both connects networks and protects the data passing between them. For example, an organization may have geographically spaced networks connected via the Internet; the company has connectivity but no privacy. The Gateway provides privacy by encrypting those connections that need to be secure. Another company may connect all ports of its geographically spaced network through the use of dedicated leased line; this company has achieved connectivity and privacy, but at great expense. Gateway offers a cheap connectivity solution by connecting the different parts of the network via the public Internet.

A VPN employs encrypted tunnels to exchange securely protected data. The Security Gateway creates encrypted tunnrls by using the Internet Key Exchange (IKE) and IP Security (IPsec) protocols - ESP (Encapsulating Security Payload). IKE creates the VPN tunnel, and this tunnel is used to transfer IPsec encoded data. Think of IKE as the process that builds a tunnel, and IPsec packets as trucks that carry the encrypted data along the tunnel.

Creating VPN tunnels between Gateways is made easier through the configuration of VPN Communities. To understand VPN Communities, a number of terms need to be defined:

* VPN Community member - The Gateway that resides at one end of a VPN tunnel.

* VPN Domain - The hosts behind the Gateway; the VPN Domain can be the whole network that lies behind the Gateway or just a section of that network. For example, a Gateway might protect the corporate LAN and the DMZ. Only the corporate LAN needs to be defined as the VPN Domain.

* VPN Site - Community member plus VPN Domain; typical VPN site would be the branch office of a bank.

* VPN Community - The collection of VPN tunnels (secure connections) and their attributes.

* Domain-based VPN - Routing VPN traffic based on the VPN Domain behind each Gateway in the Community; in a star Community, this allows satellite Gateways to communicate with each other through center Gateways.

* Route-based VPN - Traffic routed within the VPN Community based on the routing information, static or dynamic, configured on the operating systems of the Gateways.

VPN Topologies

The most basic topology consists of two Gateways capable of creating a VPN tunnel between them. Security Management Server's support of more complex topologies enables VPN Communities to be created according to the particular needs of an organization. Security Management Server supports two main VPN topologies:

* Meshed

* Star

I put again my Check Point virtual lab topology depicting the different VPN jargons used. It uses a Star VPN Community with the HQ Security Gateway (CP-SG1) as the Central gateway (Hub) and Branch Security Gateway (CP-SG2) as the Satellite gateway (Spoke).

Enable the IPsec VPN blade on the Security Gateways that will join the VPN Community. Go to Network Objects > Check Point > double-click on the Security Gateway > tick IPsec VPN under General Properties.

Identify the VPN domain (crypto ACL in Cisco) on the Security Gateway under Topology > VPN Domain > choose Manually defined and choose the Network Object. In this case it's HQ-Inside (10.1.1.0/24), which is the VPN domain in HQ Security Gateway 1. Click OK and create the VPN domain for the Branch Security Gateway 2.

 

Create the VPN Community by going to the IPsec VPN tab, which can be found by clicking on More > choose New and choose Star Community (a.k.a hub-and-spoke).

 

Under General, create a Name and optionally put a comment to easily identify the VPN Community.

 

Choose HQ-SG1 as the Center Gateway (a.k.a Hub) then click OK.

 

Choose Branch-SG2 as the Satellite Gateway (a.k.a Spoke) then click OK.

 

By default IKEv1 is used. Click Custom Encryption and choose the IKE Phase 1 and Phase 2 encryption policy. The stronger encryption is preferred but also consider the CPU and memory overhead on the Security Gateway.

 

There’s no need to create a pre-shared key for the VPN Community since it’s using the default internal RSA cert from the Security Management Server.

 

Under NAT, tick Disable NAT inside the VPN community to bypass NAT rules for the VPN Domain.

 

Create a Firewall rule to allow traffic between the source and destination VPN Domains (and vice-versa) by doing a right-click under VPN column > choose Edit Cell > choose Only connections encrypted in specific VPN communities > click Add > choose the created VPN Community then click OK. Click Save and Install Policy.

 

My 15-day trial license has already expired when so I’ve re-installed the Security Management Server and both the HQ and Branch Security Gateways for the IPsec VPN license to work and be able to push the policy.

 

I saw an elegant rule implementation wherein Network Objects in GREEN are the inside host or network, ORANGE for DMZ host or network and RED for outside host or network.  So I applied this scheme on my Firewall rules and used black for the SMS and Security Gateways.

From the HQ Security Gateway, notice the first ping had a 491 ms latency which is due to IKE Phase 1 and Phase 2 negotiation process.

 

This are the pings from Branch Security Gateway.

The IKE Phase 1 (UDP 500) is the first packet exchanged between the Security Gateways. There are two IPsec VPN key install which is represented by a PURPLE key icon, one for IKE Phase 1 and another for IKE Phase 2 (ESP). The encrypted traffic/payload is represented by a YELLOW padlock icon in SmartView Tracker.

 

In IKE Phase 1, it used an RSA signature from the Security Management Server (acting as internal CA) for the authentication.

 

The VPN Tunnel Utility (vpn tu) CLI command is commonly used to check IPsec VPNs. Type 1 to List all IKE SAs (Security Association) and type 2 to List all IPsec SAs.Press Enter to go back to the menu.