topic Re: Can we have two VPN tunnels using the same encryption domain? in General Topics

Can we have two VPN tunnels using the same encryption domain?

SriNarasimha005 — Wed, 08 Jul 2026 15:24:42 GMT

Hi,

We a pair of Checkpoint firewalls running in R82 that is connecting to a 3rd party site in Cisco router over a private MPLS link and IPSEC (Policy based VPN) is running on top of it for security purposes.

Now, we're planning to have another link at the 3rd party for redundancy. Both the links are managed by different vendors.

[Check Point Cluster XL- Active/Standby- R82]

| |

MPLS-1/Active/First ISP MPLS-2/Standby/Secondary ISP

| |

[Cisco Router-1] [Cisco Router-2]

These will be a primary and backup link and no load balancing is being used. Upon the failure of the Active link, the backup link to process the traffic.

On the checkpoint side, I will have created two interoperable objects (one for each ISP) and attach the same encryption group to each. We need to have routes destined for the 3rd party which is going to be the same across both the links with the different next-hop IP address.

Traffic will be initiated from my side as well from the 3rd party also.

1. Is it a correct approach to have the same encryption domain for both the interoperable sites in this case?

2. Should I have to proceed with the Route based VPN or Enhanced Link Selection?

3. Both the encryption domain (if used) and route towards the 3rd party needs to be identical on both the links. How to ensure that upon failure of Link-1, Link-2 is taking over?

Thank you.

Re: Can we have two VPN tunnels using the same encryption domain?

simonemantovani — Wed, 08 Jul 2026 15:27:32 GMT

It's better to configure a route based vpn, so you can control routing between the two tunnels by using dynamic routing protocol (or static routing with monitoring of the remote peer).

Overlapping of encryption domain will not guarantee you to route the traffic to the right vpn; in this situation it's recommended to use route based vpn

Re: Can we have two VPN tunnels using the same encryption domain?

PhoneBoy — Wed, 08 Jul 2026 23:28:01 GMT

The same encryption domain to two or more gateways implies a MEP configuration.

Re: Can we have two VPN tunnels using the same encryption domain?

SriNarasimha005 — Thu, 09 Jul 2026 06:24:22 GMT

Hi @PhoneBoy @simonemantovani

Thanks for the info. I believe I can proceed with the Route based VPN which doesn't require Implicit MEP.

The reason is, I see the below limitation in the link you shared above for MEP.

Important - There must be no overlap between the VPN Domain of the Primary Security Gateway and the VPN Domain of the Backup Security Gateways - no IP address can belong to both VPN Domains.

I'd like to establish an IPSEC VPN from the Checkpoint firewalls to the 2 different MPLS/Internal providers. Traffic is going to be initiated from both the sides and encryption domain is going to be identical.

The traffic should traverse via the Active link and in the event of a failure, it should fall back to the secondary link.

Initially, I was of opinion to proceed with the Enhanced Link Selection(ELS) but it seems like same encryption domain might be an issue here.

Can you please advise?

Re: Can we have two VPN tunnels using the same encryption domain?

emmap — Thu, 09 Jul 2026 06:49:21 GMT

Enhanced Link Selection would be useful if you were doing a single VPN tunnel to one remote end, but the encrypted packets could be routed via mutiple links to get there. It sounds like you want two tunnels to two different remote ends, and for traffic to route over one of them by preference. Hence people are suggesting Route Based VPNs. Route Based VPNs use empty encryption domains to establish, so the concept of overlapping encryption domains is not relevent. Both tunnels will be up, and you will use normal routing protocols established between the gateway and the two endpoints to manage the traffic routing behaviour.

Re: Can we have two VPN tunnels using the same encryption domain?

simonemantovani — Thu, 09 Jul 2026 06:51:58 GMT

I agree with @emmap ... in route based vpn the encryption domain are no more an issue, the peers negotiate the 0.0.0.0/0.0.0.0 as encyrption domain and everything can be managed with routing (static or dynamic).

Re: Can we have two VPN tunnels using the same encryption domain?

SriNarasimha005 — Thu, 09 Jul 2026 11:35:36 GMT

Hi @emmap @simonemantovani

Thank you very much for your response.

If a domain or policy-based VPN needs to be configured for any reason, could you please provide the high-level steps involved in this scenario?

I am seeking this information for my understanding 😊

Re: Can we have two VPN tunnels using the same encryption domain?

simonemantovani — Thu, 09 Jul 2026 12:27:07 GMT

In case of a route based vpn:

Configure to VTI numbered interfaces, assigning ip addresses like this:

CheckPoint VTI id 1 - 169.254.0.1 - Remote peer - 169.254.0.2

CheckPoint VTI id 2 - 169.254.1.1 - remote peer - 169.254.1.2

For each VTI on check point you need to define the peer id (this is the name of the interoperable device of the remote peer that you'll configure in SmartConsole).

Then create a VPN community by adding as the satellite gateways the interoperable devices created for the two remote peers.

In the tunnel management section, select "one tunnel per gateway pair".

For center and satellite gateways, assign an empty group as the encryption domain; this is the only difference compared with a plicy based vpn.

If you want to use dynamic routing, then you can configure BGP protocol (you can follow the advanced routing configuration guide).

If you want to configure static routing, when you configure the static route for the remote network, you define both remote next-hop (in example 169.254.0.2 and 169.254.1.2) and define a priority for these two peers (you can also enable ping option to check which peer is available).

At the end you configure the access policy (if you use BGP remember to configure policy to allow BGP protocol between your checkpoint and the remote peers).

Re: Can we have two VPN tunnels using the same encryption domain?

Bob_Zimmerman — Thu, 09 Jul 2026 14:23:09 GMT

Note that you only actually need the empty encryption domain on one end of the VPN. For example, on both of the satellite gateways for this VPN. This allows you to have route-based VPNs with some peers and domain-based VPNs with other peers.

I wouldn't use 169.254 addresses for VTIs. That block is reserved for APIPA. It would probably work (same as using addresses in 192.0.0/24, 192.0.2/24, 192.88.99/24, 198.18/15, 240/4, or other reserved blocks), but it's not guaranteed to.

When building the access rules, don't specify the VPN community in the rule (leave that column set to "Any Traffic"). Traffic over a VTI doesn't match the community.

Re: Can we have two VPN tunnels using the same encryption domain?

simonemantovani — Thu, 09 Jul 2026 14:37:49 GMT

Yes, @Bob_Zimmerman you right about access rules and also for the encryption domain, I prefer to manage a VPN completely route-based or completely domain-based just to avoid confusion.

About the IP addressese for VTIs, I always used APIPA addresses (for example if you establish a VPN with AWS, AWS use these kind of IP addresses for VTIs), but you can also use different addresses, I think there aren't any limitation, these VTIs are point-to-point connection.

Re: Can we have two VPN tunnels using the same encryption domain?

Bob_Zimmerman — Thu, 09 Jul 2026 15:09:50 GMT

@simonemantovani wrote:

Yes, @Bob_Zimmerman you right about access rules and also for the encryption domain, I prefer to manage a VPN completely route-based or completely domain-based just to avoid confusion.

Sure, but one gateway often terminates several VPNs. Changes to existing VPNs usually require cross-company coordination, so it's good to know you can do some VPNs with encryption domains and others with routes without them necessarily interfering with each other.

On the topic of IPs selection, AWS, Azure, and GCP all do wildly incorrect things with networking. They are constant sources of problems for other companies.