Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Nickel

Site to Site VPN (policy based) and routing behavior

Jump to solution

Hi!, I would like to clarify with you if the routing has precedence when we have site to site VPN tunnels created. For example, in Cisco routers/ASA, you create a crypto map with an encryption domain, so if traffic goes out to the interface which has the crypto map attached, the traffic is encypted (if the traffic matchs the encryption domain of course). But if the traffic does not go out to the interface with the crypto map due to routing, the traffic is not encrypted and is routed through a different interface.

Have we the same behavior in Checkpoint, right? Or it works in a different way? I sopose that it works in a similar way and when the tunnel is establish from the WAN interface, only the traffic which goes out through this WAN interface is the one which is encrypted, right? Thanks!

0 Kudos
1 Solution

Accepted Solutions
Highlighted

There are two ways to identify interesting traffic for VPN tunnel encryption on a Check Point: domain-based VPN and route-based VPN.  Other than how the subnets/Proxy-IDs are negotiated, the underlying VPN tunnel created is exactly the same no matter which technique you use.  It goes something like this:

1) Traffic must be accepted by the Firewall/Network policy layer first

2) If the source IP address is in the firewall's VPN domain AND (not or) the destination IP address is in the VPN domain of a peer, the traffic is interesting and will be encrypted; we do not proceed to step 3.  If the traffic is not determined to be interesting by the domains, proceed to step 3.

3) If next hop of an IP route leads to a VTI (VPN Tunnel Interface) associated with a VPN tunnel, the routed traffic is interesting and will be encrypted.  If the next hop leads to a regular interface (i.e. eth0) the traffic is not interesting and is sent in the clear.

Usually when employing route-based VPNs, the VPN domains are deliberately left empty but this is not strictly required as long as you understand that if the domains match interesting traffic it will be encrypted no matter what route-based VPN says.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com

View solution in original post

5 Replies
Highlighted

There are two ways to identify interesting traffic for VPN tunnel encryption on a Check Point: domain-based VPN and route-based VPN.  Other than how the subnets/Proxy-IDs are negotiated, the underlying VPN tunnel created is exactly the same no matter which technique you use.  It goes something like this:

1) Traffic must be accepted by the Firewall/Network policy layer first

2) If the source IP address is in the firewall's VPN domain AND (not or) the destination IP address is in the VPN domain of a peer, the traffic is interesting and will be encrypted; we do not proceed to step 3.  If the traffic is not determined to be interesting by the domains, proceed to step 3.

3) If next hop of an IP route leads to a VTI (VPN Tunnel Interface) associated with a VPN tunnel, the routed traffic is interesting and will be encrypted.  If the next hop leads to a regular interface (i.e. eth0) the traffic is not interesting and is sent in the clear.

Usually when employing route-based VPNs, the VPN domains are deliberately left empty but this is not strictly required as long as you understand that if the domains match interesting traffic it will be encrypted no matter what route-based VPN says.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com

View solution in original post

Highlighted
Nickel
Thank you very much for this.

My question is related to domain-based VPN (I have called it "Policy Based" due to Azure/AWS terminoly), so if I have understood correctly, there is no any previous routing check step before encrypting traffic if it matchs with encription domains (both, source and destination address) different to what happens in Cisco, right?

For example, lets thing about a Security Gateway with three interfaces: LAN1 (192.168.1.0/24), LAN2 (192.168.2.0/24), and WAN (81.46.1.0/29) interfaces. My local encryption domain has the network 192.168.1.0/24 and I stablish a tunnel with a remote peer which has the subnet 192.168.2.0/24 included in its Encryption Domain. What happens when the IP 192.168.1.10 tries to reach 192.168.2.10?

Thinking about Cisco, this traffic would be locally routed between LAN1 and LAN2 interfaces, but according to what I have understood, in Checkpoint this traffic would be encrypted and sent through the tunnel, right? Thanks!
0 Kudos
Highlighted

Domain-based VPNs on Check Point aren't really policy-based these days, there is an older mode for VPNs called "Traditional mode" where Encrypt actions were specified in the rulebase directly similar to policy-based.  Simplified VPN mode is the default today on Check Point and separates the specification and formation of VPN tunnels into VPN Community objects, while the access control for traffic traversing the tunnel is controlled in the security policy. 

But VPN Domains specify what will be encrypted, and if the domains match the traffic will be encrypted, period.  In your example you have an overlapping subnet (192.168.2.0/24) between your gateway and a peer.  Of course this will not work without NAT of the VPN traffic on both sides. 

In your example assuming that your firewall's encryption domain consisted only of 192.168.1.0/24 (if 192.168.2.0/24 exists in your firewall's domain as well the VPN will never even attempt to start), and traffic from 192.168.1.0/24 bound for 192.168.2.0/24 matched a peer's VPN domain, I suspect the IKE negotiations between your gateway and the peer would probably succeed, but because routing (inspection points Io) occurs before encryption (inspection points oO) the traffic would be encrypted then improperly dumped out the local directly-attached 192.168.2.0/24 interface trying to reach your VPN peer's routable IP address (or it may never actually be transmitted at all due to a reachability issue for the VPN peer IP).  So the tunnel will probably start fine and all IKE negotiations will succeed, but actual connectivity through the tunnel will not work due to the routing/overlap issue.  NAT on both sides ("double NAT") would need to be employed to get around this overlap situation.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com
0 Kudos
Highlighted
Nickel

The example above was just this, an example, and I really do not want to make work this scenario :-). I had these questions mostly because I want to stablish a new tunnel between two Security Gateways managed from the same SMS, and these Security Gateways already have Encryption Domains configured. The problem is that I just want to allow a specific traffic through this new tunnel but I cannot do it because I am using R80.20 and can just create one Encryption Domain per gateway. I just wanted to know if traffic going through different interfaces will be also affected if the subnets are included in the current Encryption Domain configuration.

Thank you very much for the help and detailed answers.

0 Kudos
Highlighted

Yep your example was an interesting thought experiment for me.  R80.40 with its per-community VPN domains would definitely be helpful in your case.

Book "Max Power 2020: Check Point Firewall Performance Optimization" Third Edition
Now Available at www.maxpowerfirewalls.com
0 Kudos