Site to Site VPN (policy based) and routing behavior

[Gusa2727]

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!

[Timothy_Hall · Accepted solution]

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 (usually specific subnets for domain-based VPNs and a "universal tunnel" which is double 0.0.0.0/0's for route-based VPN), 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.

[Gusa2727]

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!

[Timothy_Hall]

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.

[Gusa2727]

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.

[Timothy_Hall]

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.

[Nima_Chogyal]

I contacted the TAC regarding policy based VPN and they have replied that checkpoint firewalls do no support policy based VPN. Is that true? Because the central  bank in my country is trying to connect to one of the banks in India and they support only policy based VPN.

[_Val_]

@Nima_Chogyal please provide me with the case number via personal message, so I could investigate. It might be, the TAC response was for a specific configuration you wanted to use with a route-based VPN. In general, it is supported, with some limitations.

[Timothy_Hall]

I believe you misunderstood what they told you.  Policy based VPN is the old school "traditional mode" where encrypt and decrypt actions were specified directly in the rulebase action field.  This is not the same thing as domain-based which is employed with the newer simplified VPN mode which became default in R52 (may not have that version exactly right) via the introduction of VPN Communities.  

If I remember correctly existing policy packages that are set for traditional mode will still work in the latest releases if they are brought forward as part of an upgrade, but you are not allowed to create new policy packages in traditional mode nor change existing ones from simplified to traditional mode.  I believe this is what TAC meant by "not supported".  Just use domain-based VPN in this scenario which should be compatible. 

[PhoneBoy · Accepted solution]

It wasn't called R52 back then (NG FP2 was the official name), but yeah, that sounds like the right timeframe 🙂

Traditional Mode VPN technically still works, but has numerous limitations that will not be resolved.
A few examples from SecureKnowledge:

• IKEv2 Not Supported
• Route Based VPNs Not Supported
• CoreXL is Not Supported (major limitation from a performance standpoint)

There's a few things Traditional Mode allows for that can't easily be done in Simplified Mode.
This includes:

1. Allow multiple encryption algorithms per community. The workaround for this limitation is splitting up VPN communities.
2. Exclude some traffic from VPN, which can be done in the community itself as well as through some .def file modifications documented here: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 
3. Allow for a different encryption domain per community (Something R80.40 and above supports)

Unfortunately, there is not currently a simple method to convert from Traditional to Simplified Mode VPN.
R77.30 and earlier had a migration tool which had numerous limitations and has yet to be brought forward into R8x releases.