Using "Encryption Domain Per community" feature overrides Encryption Domain for other communities

Product

IPSec VPN

Version

R80.40 (EOS), R81 (EOS), R81.10 (EOS), R81.20

OS

Gaia

Last Modified

2025-10-09

Symptoms

• Encryption Domain Per Community (EDPC) allows administrators to define different IP ranges for each VPN community. This ensures traffic is encrypted according to the correct policy and prevents overlapping encryption domains across multiple VPN communities.

There are several common scenarios where overriding the default encryption domain in a specific community is useful:

• Restricting access to certain internal resources within a community.
  • Expanding access to internal networks for selected community members.
  • Hiding specific networks when using a back-to-back VPN setup with a central Security Gateway.

How It Works and possible issues

When an administrator overrides the encryption domain for a particular VPN community using user-defined networks, they often do so by breaking down an existing subnet into smaller ranges to fine-tune access.

However, because of a design limitation in the original EDPC implementation, once a subnet is split within any community, the fragmented subnets become globally visible to all other VPN communities on the same Security Gateway. This means that even those communities where the encryption domain was not overridden will now use the fragmented networks for VPN negotiation.

This behaviour is seamless when all gateways involved are Check Point devices, as they share the same implementation and accept fragmented subnets during VPN negotiation.

Note that with third-party VPN devices, this can cause interoperability issues. External peers may reject VPN negotiations if the subnet definition they expect does not match the fragmented ranges now negotiated.

Example

Suppose a Check Point Security Gateway has a backend network: 10.10.10.0 /24

A third-party VPN peer expects this full /24 range.

Now, in one community, the administrator decides to limit access and defines a User-Defined Network using EDPC: 10.10.10.8 /30

Internally, the gateway splits the original 10.10.10.0/24 into three segments:

• 10.10.10.0 – 10.10.10.7
  • 10.10.10.8 – 10.10.10.11 (10.10.10.8/30)
  • 10.10.10.12 – 10.10.10.255

After this change, all other VPN communities on the Security Gateway will also use these three fragmented ranges for negotiation - even those that did not override the encryption domain.

As a result, third-party peers that expect the original continuous /24 may fail to establish tunnels, since they now see multiple smaller ranges instead of a single block.

Solution

This problem was fixed. The fix is included in:

• Check Point R82
• Jumbo Hotfix Accumulator for R81.20 starting from Take 43
• Jumbo Hotfix Accumulator for R81.10 starting from Take 131
• Jumbo Hotfix Accumulator for R81 starting from Take 99
• Jumbo Hotfix Accumulator for R80.40 starting from Take 211

After the fix is applied, the Security Gateway keeps the original subnet definitions for communities where the encryption domain was not overridden, thereby preventing unintended fragmentation and enhancing interoperability with third-party VPN devices.

Important Consideration after applying installing the relevant Jumbo Hotfix/upgrade

• While the fix solves the original interoperability problem, it may introduce a new side effect in environments where administrators previously applied workarounds on the third-party side (for example, by adjusting the peer's configuration to match the previously fragmented subnets).
• After upgrading to a version with the fix, these peers may now experience a mismatch because the Security Gateway reverts to advertising the original, unsplit subnet ranges.
• If you previously modified third-party VPN configurations to match fragmented ranges, review and adjust them back to the correct original subnets after upgrading.

Behaviour Change Summary

• Before upgrade: Overriding an encryption domain caused all VPN communities to use fragmented subnets, which could break tunnels with third-party devices.
• After upgrade (fixed behaviour): Only the modified community uses fragmented networks; others keep their original subnets.
• Action required: If you adapted third-party peers to match the old, fragmented subnets, update their settings to match the original ranges to avoid new mismatches after upgrading.

NOTE

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.