7.1 Site-to-Site IPsec VPN

Site-to-Site IPsec VPN on R82

A site-to-site VPN connects two (or more) fixed networks over an untrusted transport — usually the public internet — by encrypting traffic between two Check Point Security Gateways. On R82 the IPsec VPN Software Blade is enabled per-gateway, and the tunnel is defined by adding both gateways to a VPN Community object rather than by writing per-peer crypto map entries as you would on a generic router. The CCSA exam expects you to know the two IKE phases, the default R82 suites, the difference between Main Mode and Aggressive Mode, the role of the VPN Domain, and the basic workflow for building a tunnel between two gateways.

IPsec Quick Refresher

IPsec uses two protocols: ESP (Encapsulating Security Payload, protocol 50) for data encryption and integrity, and AH (Authentication Header, protocol 51) for integrity only — ESP is what you almost always use on R82. The protocol runs in tunnel mode by default (the entire IP packet is encrypted and wrapped in a new IP header); transport mode is for host-to-host edge cases. Because ESP and IKE (UDP 500/4500) are routinely blocked or mangled by NAT devices, NAT-T (NAT Traversal, UDP 4500) encapsulates ESP in UDP when a NAT box sits between peers, and the IKE payload keeps the original source/destination in the inner header.

IKE Phase 1 — Building the Secure Channel

IKE Phase 1 authenticates the two peers and produces an IKE Security Association (SA) — a secure, management-only channel used to negotiate the data SAs in Phase 2. Authentication is by pre-shared secret or certificate issued by the Internal Certificate Authority. A Diffie-Hellman exchange creates shared key material, and the peers agree on the Phase 2 methods to use later.

R82 default Phase 1 settings: AES-256 encryption, SHA-1 integrity, DH Group 15 (3072 bits). Available alternatives include AES-128, AES-GCM-128/256, SHA-256, SHA-384, SHA-512, and DH Groups 1, 2, 5, 14, and 16–21. IKE Phase 1 SAs are rekeyed once per day by default. Stronger is not always better: higher DH groups cost more CPU on every rekey, which matters on small appliances.

Two modes exist for IKEv1:

In R82.10 the default is IKEv2 only; on R82 you typically select Prefer IKEv2, support IKEv1 for mixed-vendor environments. IPv6 VPN requires IKEv2. Dead Peer Detection (DPD) keeps the SA alive across idle periods and detects a dead peer quickly — enabled by default on R82.

IKE Phase 2 — The IPsec Data SA

Phase 2 uses the secure channel from Phase 1 to negotiate the IPsec SA that actually carries user traffic. R82 defaults: AES-128 encryption, SHA-1 integrity, with the SA rekeyed every hour. Perfect Forward Secrecy (PFS) is optional; when enabled, a fresh DH key is generated for each Phase 2 exchange (default DH Group 15). The VPN Domain (encryption domain) on each side determines what source/destination traffic is eligible to be encrypted into the SA.

Tunnel Between Two Gateways — Workflow

Building a tunnel between Gateway A and Gateway B follows the same workflow every time:

1. Enable the IPsec VPN Software Blade on both gateways.
2. Configure each gateway's VPN Domain (encryption domain) — the networks behind it that should be encrypted.
3. Create a Meshed VPN Community (for two peers, meshed and star behave the same).
4. Add both gateways to the community and accept default Phase 1/Phase 2 suites unless interoperability demands otherwise.
5. Create an Access Control rule with the VPN community selected in the VPN column so matched traffic is encrypted.
6. Install the Access Control Policy on both gateways.
7. Generate traffic that matches the rule and verify in SmartConsole Logs that you see Encrypt and Decrypt log entries (and key install for the IKE SA).

Verification Commands

From clish or expert mode use the following to confirm tunnel state:

• vpn tu — interactive Tunnel Utility; shows and resets IKE and IPsec SAs (option T to reset all IKE SAs, R to reset all IPsec SAs).
• fw monitor with the e/E masks to confirm packets enter the encrypt path.
• SmartConsole → Logs → filter on blade:"VPN" to see IKE negotiations, key installs, and any failures. Look for IKE Peer not reachable, Main Mode failed, or No proposal chosen.
• cpview → VPN section for live SA counters (encrypted/decrypted bytes).

Common CCSA Traps

• VPN Domain empty or mis-scoped. If the encryption domain on one side does not include the source subnet and on the other side the destination subnet, traffic will be sent in clear and likely dropped by the implied VPN rule. Default is "All IP Addresses behind Gateway based on Topology" — change it only when you have an asymmetric topology.
• Mixing IKEv1 Aggressive Mode with Main Mode on the same community is not supported; pick one and match it on both ends.
• Lifetimes can be tuned, but a Phase 2 lifetime much shorter than Phase 1 causes frequent rekey storms. Defaults (1 day / 1 hour) are the right answer unless the question gives you a reason to change them.
• Pre-shared secret mismatch is the single most common cause of Phase 1 failure; the log shows IKE Peer not reachable or Main Mode failed.
• VPN column empty means traffic is sent in clear even though both gateways are in the same community — the rule, not the community, triggers encryption.