Set Up a Site-to-Site VPN Community on Check Point (R81.20)

Before you run this

This guide builds a site-to-site IPsec VPN community in Check Point SmartConsole so traffic between two sites' encryption domains is tunnelled and encrypted. The main path assumes both peers are Check Point gateways managed by the same Management Server (SMS) on R81.20; I note where a third-party peer (an Interoperable Device) differs.

This is not a shell script — it is a change made in SmartConsole and pushed with Install Policy. You need a SmartConsole login with read/write administrator permissions on the Management Server. For the verification steps you also need expert mode (root) on the gateway CLI.

Treat this as a production-affecting change:

Keep an out-of-band path open. Do your work over a console/serial or a management interface you know the new VPN and its access rules cannot touch. A wrong encryption-domain or a rule change can black-hole management or production traffic.
Back up first. On the Management Server, take a database revision (SmartConsole marks one automatically on each policy install, but confirm) and a Gaia snapshot on both the management and the gateways before you install policy. On each gateway, add snapshot <name> in clish, or use the Gaia WebUI Maintenance → Snapshot Management.
Do it in a maintenance window. Building the community changes nothing until you Install Policy; that install is the moment traffic behaviour changes.
Rollback path: revert to a previous policy by installing an earlier database revision in SmartConsole (Manage & Settings → Revisions), and roll a broken gateway back with a Gaia snapshot revert (set snapshot revert <name>). Test the whole thing between lab gateways or a single test subnet before you point production networks through it.

Nothing here deletes data, but an incorrect VPN domain or NAT interaction can silently drop production flows, so verify with vpn tu before you call it done.

What you're assuming

Check Point R81.20, Gaia, one Management Server, two managed gateways (gw-siteA, gw-siteB).
The IPsec VPN software blade is licensed on both gateways.
Each site's protected subnet is already defined as a network object.
Both gateways get their VPN certificates from the management's Internal CA (ICA) — the default when both are managed by the same SMS. A third-party peer instead uses a pre-shared key.

Step 1 — Enable the IPsec VPN blade on each gateway

In SmartConsole:

Gateways & Servers → double-click gw-siteA.
On General Properties, tick IPSec VPN under Network Security blades.
Repeat for gw-siteB.

Don't install policy yet.

Step 2 — Define each gateway's encryption domain (VPN domain)

The VPN domain is the set of internal networks a gateway advertises into the tunnel. Get this wrong and traffic either won't match the tunnel or will be encrypted when it shouldn't be.

Create (or reuse) a network object or a group for each site's protected subnets — e.g. net-siteA-lan (10.10.0.0/16) and net-siteB-lan (10.20.0.0/16).
Open gw-siteA → Network Management → the VPN Domain setting.
Choose either:
- All IP Addresses behind Gateway based on Topology information — fine if the gateway's interface topology already describes exactly what you want to encrypt; or
- Manually defined, pointing at your group (net-siteA-lan).
For anything non-trivial I use Manually defined, because it makes the encryption domain explicit and reviewable.
Repeat on gw-siteB with net-siteB-lan.

If you can't find the VPN Domain control in your build, it's documented in the R81.20 Site-to-Site VPN Administration Guide under configuring the VPN domain — check there rather than guessing.

Step 3 — Create the VPN community

A Meshed community connects every member to every other member directly. A Star community connects satellites to one or more central gateways and is the usual choice for hub-and-spoke. For two peers, Meshed is the simplest and correct choice.

In SmartConsole, open the Objects menu → More object types → VPN Community → New Meshed Community (a Star option lives beside it).
Name it, e.g. vpn-siteA-siteB.
On the Gateways page, add gw-siteA and gw-siteB as participants.

Step 4 — Set encryption and authentication

Still inside the community object:

On the Encryption page, choose the encryption method — prefer IKEv2 where both peers support it — and an encryption suite. Check Point ships named suites (e.g. the Suite-B presets) plus a Custom Encryption option for setting Phase 1 / Phase 2 algorithms explicitly.
The two peers must agree on every Phase 1 and Phase 2 parameter — encryption, integrity/hash, DH group, and lifetimes. With two Check Point gateways this is automatic once both use the community's settings. With a third-party peer, write the values down and configure the far end to match exactly; a single mismatch is the classic "Phase 1 never completes" call.
Authentication: two same-managed Check Point gateways authenticate with certificates from the ICA automatically — nothing to configure. For an Interoperable Device, set a pre-shared secret in the community's shared-secret settings for that member and enter the identical key on the third-party device.

On Tunnel Management you can leave the default (one tunnel per pair) unless the peer needs subnet-based tunnels or permanent tunnels — see the admin guide before changing it.

For a third-party peer, first create it via Objects → New → More → Network Object → Interoperable Device, define its topology/encryption domain, then add it to the community in place of a second Check Point gateway.

Step 5 — Add the access rule

Building the community does not by itself permit traffic. The Access Control policy still decides what passes.

Go to Security Policies → Access Control → Policy.
Add a rule:
- Source: net-siteA-lan
- Destination: net-siteB-lan (and a second rule, or an "Any"-direction VPN column, for the return direction)
- VPN column: set it to your community vpn-siteA-siteB (right-click the VPN cell → Specific VPN Communities → add it). Leaving this as Any would also match clear traffic — scope it to the community.
- Services & Applications: the ports you intend to allow (don't reflexively use Any).
- Action: Accept, and set Track to Log.
Place the rule where it will be matched before any broad cleanup/deny rule.

Step 6 — Install policy

Install Policy (top toolbar) → select both gateways → install the Access Control policy.
Watch the progress; a verification error here (overlapping encryption domains, missing blade) will stop the install before anything reaches the gateways — read it, fix it, re-install.

Verify it worked

Generate traffic from a host in net-siteA-lan to one in net-siteB-lan, then on the gateway in expert mode:

# Interactive tunnel utility: list SAs, view IKE/IPsec state, delete SAs to force re-key
vpn tu

# Non-interactive view of established tunnels and peers
vpn tunnelutil

Choose the option to list all IKE SAs and to list all IPsec SAs — you should see a Phase 1 SA and Phase 2 SAs for the peer gateway. In SmartConsole, open Logs & Monitor → Logs and filter on the peer; you want to see traffic logged as Encrypt/Decrypt on your new rule, not Accept in the clear and not Drop.

If Phase 1 fails, the log's information field usually names the mismatch (proposal, peer identity, or certificate). Recheck Step 4 on both ends.

Undo / roll back

Remove the tunnel cleanly: in SmartConsole, take the members out of the community (or delete the community object) and remove or disable the VPN access rule, then Install Policy again.
Force a re-key while testing: in vpn tu, delete the SAs for the peer — the tunnel rebuilds on the next matching packet, non-destructively.
Full rollback: install a previous database revision (Manage & Settings → Revisions) to restore the prior policy, and if a gateway itself is misbehaving, revert its Gaia snapshot taken in the safety step.

For exact parameter names and the current supported IKE/IPsec suites, work from the Check Point R81.20 Site-to-Site VPN Administration Guide on Check Point's support site rather than from memory — the encryption presets in particular change between releases.