IPsec encryption domain

[D@1984]

Hi, can someone please explain in case of having encryption domains rather than having a route- based IPsec, do the encryption domains have to match at both sides? For instance if I have local:10.20.1.0/24 and 10.40.0.0/24 and remote: 192.168.72.0/24, then I will have two encryption domains one from 10.20 to 192.168 and the other from 10.40 to 19.168. I assume then remote site, have to have also two domains one from 192.168 to 10.20 and the other to 10.40 ? Does the subnet mask has to be exact same match ? So if remote peer have 192.168 to 10.0.0.0/8, does this cause traffic to be dropped? Is this standard for all vendors? I guess what I’m trying to understand is for phase 2, is encryption domains one of the things that peers check like HAGEL? Thanks 

[Rob Ingram]

D@1984 using a policy based VPN, the networks that define the interesting traffic to be encrypted (aka encryption domain) need to match. Some vendors like Check Point are not so strict on that requirement, which can cause some pain when setting up and troubleshooting a VPN with other vendors. To avoid issues, you should configure the the traffic selectors (network/mask) to be the mirror of the peer.

[D@1984]

Thanks, from experience, do you know what kind of impact we might see? 

[Sheraz.Salim]

Policy-based IPSec VPNs with encryption domains require exact matching between both peers for successful tunnel negotiation and traffic flow. The encryption domains, also known as proxy IDs or traffic selectors, must be mirrored on both sides of the VPN connection. For example, if the local side defines domains as 10.20.1.0/24 and 10.40.0.0/24 (source) with a remote domain of 192.168.72.0/24 (destination), the remote peer must configure two corresponding domains: 192.168.72.0/24 (source) to 10.20.1.0/24 (destination), and 192.168.72.0/24 (source) to 10.40.0.0/24 (destination).

Subnet masks must match precisely between peers. A broader mask like 10.0.0.0/8 on the remote side would not correctly encrypt traffic from more specific networks like 10.20.1.0/24 or 10.40.0.0/24. Mismatched subnet masks typically result in traffic drops or tunnel establishment failures.

Different vendors handle encryption domain matching with varying levels of strictness. Cisco and Oracle, for instance, enforce exact matches for Phase 2 security association (SA) negotiation. In contrast, Check Point and Palo Alto may be more flexible, potentially accepting broader ranges but risking interoperability issues with other vendors.

Mismatched encryption domains can lead to several problems:

Complete tunnel failure or a "Partial UP" state if even one SA pair mismatches.

Traffic drops for packets not matching the negotiated domains.

Increased complexity in debugging, especially in multi-vendor environments.

For optimal performance and compatibility, it's recommended to use route-based VPNs with Virtual Tunnel Interfaces when possible. If policy-based VPNs are necessary, ensurey all encryption domains are precisely mirrored, subnet masks match exactly, and avoid overlapping CIDR blocks between local and remote networks.Always test interoperability during initial setup, particularly in mixed-vendor scenarios.

In Phase 2 negotiations, encryption domains are as critical as HAGLE (Hash, Authentication, Group, Lifetime, Encryption) parameters, they must align precisely for the VPN tunnel to function correctly.

[MHM Cisco World]

Yes friend you can not use 10.0.0.0/8

There is be conflict between two VPN tunnel

You must use /24

MHM