Route VPN traffic between two 3rd parties using CheckPoint

Long time no see! Been a crazy couple of months over here. I’ve managed to pass my CCSA and, unfortunately, fail my driving license! Seems like I’ve another month or two of cycling to work. I consider it a good thing though. Sitting in front of a screen for 8 hours with rather short breaks can not (and most certainly isn’t) be good for me.

Anyway!

Let’s imagine a scenario when we have two 3rd parties that would like to access each other’s resources. I’m going to assume you already have a VPN established with each one of those satellites. Those are policy-based (therefore not routed) VPNs:

CheckPoint encryption domain – 10.0.100.0/24
Satellite no.1 encryption domain – 10.0.110.0/24
Satellite no.2 encryption domain – 10.0.120.0/24

Now, before we being, let’s think about what we already have and what we want to achieve:

In policy-based VPN, encryption domains are used by the gateways to establish Security Associations (This happens in phase 2). Security Associations are essentially agreements between two VPN peers on what subnet on one side can securely pass traffic to a subnet on the other side. We can have many SAs, depending on the number of subnets we include in our encryption domains. Those SAs are used by gateways to decide what to do with the traffic once it arrives at the gateway. If traffic from 10.0.110.0/24 subnet arrives at Satellite no.1 gateway with destination IP sitting somewhere on 10.0.100.0/24 subnet, the gateway will use Security Association between 10.0.110.0/24 and 10.0.100.0/24 as a “road sign” indicating that this packet is supposed to be encrypted and sent over the tunnel, because the destination is on the other side of the VPN.

To allow 10.0.110.0/24 (Satellite no.1) to communicate with 10.0.120.0/24 (Satellite no.2) subnet, we essentially want to create additional SAs between CheckPoint and each one of the satellite gateways to let them pass traffic intended to go to the other satellite over the VPN. Okay, hope I didn’t lose you here. I’m bad at wording stuff, hopefully the picture below will make more sense.

This is what we have right now:

And this is what we’re going to do:

As you can see, we’ve introduced second SA. The new SA2 is essentially identical for both Satellites as the communication will be happening between those two Satellites and our CheckPoint box will be a middleman.

Right now, if we try to ping from Satellite 2 10.0.120.1 interface from Satellite 1’s 10.0.110.1 interface we will see that nothing happens, as expected:

Since there’s no phase 2 established for 10.0.110.0/24 and 10.0.120.0/24 subnets, our TECDEN-OPNSENSE1 (Satellite1) machine doesn’t really know where to route this traffic. So it simply sends it out to the default gateway and hopes for the best. Right. How do we correct it then?

Luckily, on CheckPoint side it’s just a matter of two changes:
On both our VPN communities (CP <–> Satellite1 and CP <–> Satellite2) we simply go to Advanced > VPN Routing and we change from this:

To this:

This should allow both communities to route through our CheckPoint device and access other VPNs.

On our 3rd parties, however, the change will take a little more effort:

Since in this example I’m using OPNSense routers as Satellites, I’m going to add another Phase2 entry.

On Satellite1:
Mode: Tunnel IPv4
Local Network Type: STUBNET_10_0_110_0 subnet (this will be your encryption domain that you want to make available for Satellite 2)
Remote Network Type: Network
Address: 10.0.120.0/24 (Satellite 2 encryption domain)
Protocol: ESP
Encryption algorithms: AES 128 bits
Hash algorithms: SHA1
PFS key group: off
Lifetime: 3600

On Satellite2:
Mode: Tunnel IPv4
Local Network Type: STUBNET_10_0_120_0 subnet (this will be your encryption domain that you want to make available for Satellite 1)
Remote Network Type: Network
Address: 10.0.110.0/24 (Satellite 2 encryption domain)
Protocol: ESP
Encryption algorithms: AES 128 bits
Hash algorithms: SHA1
PFS key group: off
Lifetime: 3600

So in the end my Satellite1 config will look like this:

And Satellite2 config:

Now, save and apply the changes and let’s test it!

I’m going to do the same ping test I did before we began:

Woohooo! How does it look like on the CheckPoint side?

If you can see “VPN Routing” log entries then it means the VPN(s) are working as expected 🙂

Let’s check active Phase2’s on all devices.

CheckPoint:

Satellite1:

Satellite2:

I’ve marked second phases to picture how the satellites create extra SAs for the routed traffic. (Also I really appreciate how clear OPNSense and all StrongSwan implementations are about SAs. Look at CheckPoint and tell me what you can make out of this without looking at vpn_routing table!)

Hopefully that makes this rather basic topic a little easier for those new to CheckPoint and networking in general. Let me know what you think of this in the comments! Also, guide suggestions are highly appreciated 🙂

Leave a Reply

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

Navigation