Defining encryption domains per VPN peer in CheckPoint

Prologue

Note: If you’re familiar with the concept of VPN communities and built-in mechanisms used by CheckPoint, skip this section and head straight to the “Solution” section.

Vendors generally implement VPNs in a way where phase 1 and phase 2 settings are defined per VPN peer (aka 3rd party we will be establishing the VPN tunnel with) which gives us the flexibility in regards to subnets we will be using for phase 2. If that sentence didn’t make sense, lets look at the screenshot below:

OPNSense’s IPSec tunnel settings view

Green colour represents phase 1 entries. As you can see, each phase 1 is associated with settings defining phase 2. Each active phase 2 is highlighted by purple colour whereas inactive entries are highlighted red colour. Each entry defines a relationship between a single local and remote subnet.

OPNSense, as well as pfSense, Cisco ASA and tons of other vendors allow you to specify phase 1 and phase 2 settings that way. It makes sense, right? Requires a little bit more configuration but gives a great visibility of each VPN peer and their settings.

Well, CheckPoint is different. In CheckPoint you can define all phase 1 and some phase 2 settings per VPN peer by using “VPN Communities”. Situation is a little bit different when it comes to the subnets used for Security Associations (the relationships I mentioned two paragraphs above). We specify the subnets on per-object basis. What does that mean for us? Let’s imagine following scenario:

We have two VPN peers (PeerA and PeerB) we (TecDen) will be creating separate tunnels with:

  • Peer A: 10.0.110.0/24
  • Peer B: 10.0.120.0/24

Peer A is supposed to establish an SA with 172.16.110.0/24 subnet on TecDen’s end whereas Peer B will need access to 172.16.120.0/24.

In OPNSense, we just define two separate Phase 1 entries, each with a single Phase 2 entry:
Peer 1 Phase 2:
172.16.110.0/24 (Local Network) == 10.0.110.0/24 (Remote Network)
Peer 2 Phase 2:
172.16.120.0/24 (Local Network) == 10.0.120.0/24 (Remote Network)

In CheckPoint’s case, we can’t easily do this because we only have a single object representing “us”, therefore, we will need to add both subnets (172.16.110.0/24 and 172.16.120.0/24) to the object representing TecDen in order to successfully establish SAs with each peer:

SmartDashboard (R77.30) view. It looks exactly the same in R80.X SmartConsole

It’s all fun and games until you add a bunch of networks. See, CheckPoint (by default in R80.X) tries to maximize performance by supernetting subnets so in a situation where you would normally establish two separate SAs for subnets 172.16.100.0/24 and 172.16.101.0/24, CheckPoint will supernet those subnets and establish a single SA using 172.16.100.0/23 subnet.

This works well as long as all our VPNs will be created between hosts that are managed by the same SMS (Security Management Server) because all hosts are “aware” what happens and will be prepared for this eventuality. This won’t be the case when we want to establish a VPN with 3rd party that will only accept SAs between the subnets they’ve configured their tunnels with – so two /24 instead of a single /23 supernet.

Fear not! There is, luckily, a way to “overwrite” CheckPoint’s built-in mechanisms and essentially switch to the per VPN peer settings. And it’s not pretty.

Solution

Let’s start off disabling the supernet mechanism first. There is an option to switch off the supernetting mechanism for all 3rd party devices.

Head to C:\Program Files (x86)\CheckPoint\SmartConsole\RXX.XX\PROGRAM and launch GuiDBedit.exe

Note: Path might be different for R80.X consoles since they’re actually 64-bit programs now.

Log in to the management server using your usual credentials.

Head to Table > Global Properties > properties and, in the list of properties, find “ike_enable_supernet”. Double-click the record and change the value to “False”:

Press “OK”. Head to File -> Save all and close the GuiDBEdit.

Now, connect to the management server using SSH. Make sure you’re in an expert mode for following steps.

#Backup the file we will be editing
cp $FWDIR/conf/user.def.FW1 $FWDIR/conf/user.def.FW1.bak

Now open the file with your favourite file editor.

vim $FWDIR/conf/user.def.FW1

In the file specify your desired phase 2 settings following example below. Ensure whatever you put into the file goes ABOVE line that says “#endif /* __user_def__ */” and below a line that says “User defined INSPECT code”. If you wish to only override one problematic subnet for peer 172.16.10.10, do:

#ifndef __user_def__
#define __user_def__

//
// User defined INSPECT code
//

subnet_for_range_and_peer = {
<172.16.10.10, 10.0.100.1, 10.0.100.62; 255.255.255.192>
};


#endif /* __user_def__ */

For multiple subnets, do:

#ifndef __user_def__
#define __user_def__

//
// User defined INSPECT code
//
subnet_for_range_and_peer = {
<172.16.10.10, 10.0.100.1, 10.0.100.62; 255.255.255.192>,
<172.16.10.10, 10.255.1.1, 10.255.1.62; 255.255.255.192>,
<172.16.10.10, 192.168.10.1, 192.168.10.254; 255.255.255.0>
};


#endif /* __user_def__ */

The general pattern is:

subnet_for_range_and_peer = {
<vpn_peer_ip, range_one_begin, range_one_end; subnet_mask>,
<vpn_peer_ip, range_two_begin, range_two_end; subnet_mask>
};

vpn_peer_ip – the 3rd parties IP. This is not our IP.
range_x_begin – first IP address in the subnet you want to overwrite
range_x_end – last IP address in the subnet you want to overwrite
subnet_mask – self explanatory

Bear in mind you can’t include broadcast or network addresses. Only first and last host addresses.

Now, head to the SmartConsole/SmartDashboard and Publish & Install the policy on the gateway.

You should be able to establish VPNs successfully using the new settings 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

Navigation