7.3 Encryption Domains and VPN Communities
Key Takeaways
- The VPN Domain (encryption domain) is a per-gateway property defining the networks behind it that should be encrypted.
- Meshed communities build tunnels between every pair of gateways; Star communities build only spoke-to-hub tunnels and require spoke-to-spoke traffic to transit the hub.
- Specific VPN Domain per Community (R80.40+) lets a gateway present different encryption domains to different communities.
- R82 introduced Quantum Safe Key Exchange via IKEv2 Intermediate Exchange (RFC 9242) and Multiple Key Exchanges (RFC 9370).
Encryption Domains and VPN Communities
Two object types control what gets encrypted and between which gateways: the VPN Domain (also called the encryption domain) and the VPN Community. CCSA candidates consistently lose points here because the two are easy to conflate, so treat them as separate layers. The VPN Domain is a per-gateway property; the VPN Community is a multi-gateway topology object that references those gateways and the encryption parameters they will use.
VPN Domain (Encryption Domain)
The VPN Domain is a property of a single Security Gateway. It is the set of IP addresses and networks behind that gateway that should be carried inside the VPN tunnel when matched against a community rule. Two configuration modes exist:
- All IP Addresses behind Gateway based on Topology (default) — derived automatically from interface topology and is correct for almost all standard deployments.
- User-defined — manually specify Network, Network Group, or Address Range objects. Use this when topology is asymmetric, when interfaces are not configured, or for third-party interoperability.
Advanced options:
- Exclude gateway's external IP addresses from the VPN Domain — important when interoperating with third-party peers that otherwise include the WAN interface in the encryption domain.
- Specific VPN Domain per Community (R80.40+) — a single gateway can present different encryption domains to different communities. Useful in hub-and-spoke where the hub participates in both a partner mesh and an internal star.
VPN Communities — Topologies
A VPN Community is a named object that defines which gateways can negotiate tunnels with each other and the Phase 1 / Phase 2 parameters they will use. Two topologies:
| Topology | Behavior |
|---|---|
| Meshed | Every gateway has a tunnel to every other gateway — full mesh. Scales poorly beyond a handful of sites because the number of tunnels is N×(N-1)/2. |
| Star | Hub-and-spoke. Each satellite gateway tunnels only to the central hub, not to other satellites. |
Communities can be combined — for example, a Meshed community between two regional hubs plus a Star community for branch offices that tunnel only to their regional hub. Branch-to-branch traffic must traverse the hub. Backup hubs can be configured in a Star community so a spoke fails over to a secondary hub if the primary is unreachable.
How the Rule Base Uses Communities
Encryption is triggered by the VPN column of an Access Control rule. When you select a community in that column, the gateway encrypts matched traffic to peers in the community. If you leave the VPN column empty, traffic is sent in clear even if both source and destination sit behind gateways in a community. The community object is what the rule references; the VPN Domain is what determines which subnet behind each gateway is encrypted.
Default Suites and Advanced Settings
In a new community R82 ships with conservative defaults that match modern best practice:
- Phase 1: AES-256, SHA-1, DH Group 15, 1-day rekey.
- Phase 2: AES-128, SHA-1, PFS optional (Group 15 when enabled), 1-hour rekey.
- IKE version: Prefer IKEv2, support IKEv1 (select IKEv2 only for new pure-Check-Point deployments).
- Quantum Safe Key Exchange (R82+) — opt-in via IKEv2 Intermediate Exchange (RFC 9242) and Multiple Key Exchanges (RFC 9370) for post-quantum readiness. Best practice: IKEv2 only, AES-256, SHA-384, DH group > 15, PFS enabled.
NAT-T and Route Considerations
Because ESP (IP protocol 50) does not pass through most NAT devices cleanly, R82 enables NAT-T by default — ESP is encapsulated in UDP 4500 when a NAT box is detected between peers. On the routing side, the gateway's encryption domain must overlap with what the peer expects to encrypt, and the peer's encryption domain must overlap with what the local gateway expects to decrypt. Mismatched encryption domains are the second most common site-to-site failure after pre-shared secret mismatch.
Backup Hubs and Failover
In a Star community you can designate a Backup Hub so spokes fail over to a secondary hub if the primary is unreachable. Failover is automatic and triggered by DPD; when the primary hub's SAs expire without DPD responses, the spoke re-negotiates to the backup. Spokes cache their IKE SAs to the primary and try to return to it when it recovers. For mission-critical hub-and-spoke designs, configure the backup hub in a different physical site — a backup hub in the same data center does not protect you against a power or network outage. Note that spoke-to-spoke traffic through a backup hub still has to traverse it just like the primary, so design routing accordingly.
Common Traps
- Forgetting to exclude the external interface when interoperating with a third-party peer, which causes the peer's IP to be included in the encryption domain and Phase 1 to fail.
- Assuming a Star community encrypts spoke-to-spoke traffic — it does not. Traffic between two spokes must transit the hub.
- Selecting IKEv1 Aggressive Mode when the peer expects Main Mode, or vice versa — pick one and match it on both ends.
- Setting the VPN domain to user-defined but forgetting a subnet, so part of the internal network is sent in clear and dropped by the implied VPN rule on the peer.
- Setting the IKEv2 only mode when one peer is a third-party gateway that supports IKEv1 only.
In a Star VPN community with Hub H and satellites S1 and S2, what happens when S1 sends traffic to a host behind S2?
What does the VPN column of an Access Control rule actually do?