One Tunnel per GW pair

[Vilius]

Hello,

We Policy based IPsec VPN with encryption group with a lot of small subnets / hosts due to historic reasons. It does not summarize well, and we found that we are having VPN issues when using "One tunnel per subnet pair" VPN tunnel sharing option. Issue is resolved if we switch to "One tunnel Per Gateway pair" option.

> However, how does encryption domain work exactly and is even valid option when using Policy based VPN? 

• One VPN Tunnel per Security Gateway pair - One VPN tunnel is created between peer Security Gateways and shared by all hosts behind each peer Security Gateway. 

If it does match what is in encryption domain and just traffic put into same tunnel, it should work. However alternative explanation suggests 

One VPN tunnel per gateway pair - Propose a universal tunnel which is 0.0.0.0/0 for source and 0.0.0.0/0 for destination. This should generally only be used for a route-based VPN setup involving VTIs.

If this explanation is true, in theory it should pull all the traffic into the tunnel when used with Policy based VPN? Can "One tunnel Per Gateway pair" be even used with Policy based VPN or it is something that is not recommended? 

Our tests suggested it works as expected and still processes listed encryption domain, but exact mechanism is not clear (or is it even supported solution)

Thanks

[_Val_]

One tunnel per gateway is a good option, and it is also saving quite a few efforts to maintain multiple SAs. 

The only concern here, however minimal, is about an attack on your VPN traffic. With other options, you will have multiple VPN tunnels with different encryption keys. So if an attacker can figure out one of them, just part of the traffic is vulnerable. 

In the case of "one tunnel per pair of GWs", if the encryption key is leaked or reverse-engineered somehow, all VPN traffic becomes vulnerable. 

You can mitigate that risk by using the strongest encryption available, strong authentication, and frequent key negotiations.

[the_rock]

I totally agree with all @_Val_ has said. By the way, there were few posts/discussions about this on the community before and conclusion is that its always best to use "per gateway" option when using route based tunnel and also when you have a combination of hosts/subnets, rather than just either one.

Hope that helps.

Andy

[CheckMatesAI]

This answer is provided by Infinity AI Copilot and should be confirmed by reviewing official documentation in Support Center.

The "One Tunnel per Gateway pair" option is indeed a valid and supported configuration for Policy-based IPsec VPNs in Check Point environments. This setting creates a single VPN tunnel between peer Security Gateways, which is shared by all hosts behind each peer gateway. This can be beneficial in scenarios where you have many small subnets or hosts, as it simplifies the tunnel management by reducing the number of tunnels required.

In your case, switching to "One Tunnel per Gateway pair" resolved the VPN issues you were experiencing with the "One tunnel per subnet pair" option. This is because the former option aggregates all traffic between the gateways into a single tunnel, which can help in environments with complex or numerous subnets.

Regarding the encryption domain, even when using the "One Tunnel per Gateway pair" option, the traffic is still processed according to the defined encryption domains. This means that the traffic selectors are still respected, and only the traffic that matches the encryption domain will be allowed through the tunnel.

While this configuration is generally more associated with route-based VPNs, it can be used effectively with policy-based VPNs, especially in complex network environments. Your tests confirming that it works as expected align with Check Point's capabilities.

For more detailed information, you can refer to the R82 Site to Site VPN Administration Guide.