Who rated this post

Executive Summary

Check Point Quantum SD-WAN is policy-driven traffic steering on top of classic routing/VPN. Most “mysterious” outages come from three failure domains:

1. VPN Link Selection ambiguity when SD-WAN is down or when peers are mixed (SD-WAN + non-SD-WAN). (sc1.checkpoint.com)

2. SD-WAN rule matching mistakes where “breakout” rules unintentionally capture VPN or non-Internet traffic, forcing cleartext egress or breaking overlay resiliency. (sc1.checkpoint.com)

3. Probing asymmetry (ICMP Echo Requests vs Replies) and missing overlay “catch-all” rules that prevent overlay probing and SLA measurement from converging. (sc1.checkpoint.com)

This article rewrites your draft into a technically rigorous, operations-focused best-practices guide aligned with Check Point’s official behavior and terminology.

1) VPN Link Selection: design for SD-WAN service failure and mixed communities

1.1 Baseline principle

Always configure IPsec VPN Link Selection in the Security Gateway object. The rationale is resilience: if SD-WAN services are not running for any reason, the gateway still has deterministic interface selection for Site-to-Site VPN. (sc1.checkpoint.com)

1.2 What actually happens in different peer combinations

Case A — SD-WAN ↔ SD-WAN peers in the same VPN community
When two or more gateways with SD-WAN enabled participate in the same Site-to-Site VPN community, they automatically initiate tunnels between their SD-WAN interfaces and interface selection is driven by WAN Link Mapping, not the classic SmartConsole Link Selection page. (sc1.checkpoint.com)

Case B — SD-WAN ↔ non-SD-WAN peer in the same VPN community
If an SD-WAN gateway participates in a VPN community with a gateway without SD-WAN, the SD-WAN gateway uses the SmartConsole Link Selection configuration for IPsec VPN. (sc1.checkpoint.com)

1.3 Practical best practices

• Always populate Link Selection even if your primary design is SD-WAN-based. It is your “service-down fallback.” (sc1.checkpoint.com)

• Standardize WAN Link Mapping for all SD-WAN members (consistent mapping is critical for predictable tunnel formation among SD-WAN peers). (sc1.checkpoint.com)

• If you are in a transitional environment (some peers SD-WAN, some not), treat Link Selection as a first-class artifact and test failover explicitly.

2) SD-WAN Policy Rule Matching: prevent breakout from hijacking VPN and non-Internet flows

2.1 Core behavior you must internalize

• The gateway matches the first applicable SD-WAN Policy rule and stops processing. (sc1.checkpoint.com)

• SD-WAN breakout-style rules behave similarly to Policy-Based Routing (PBR): they can override OS routing, including directly connected networks, when the rule matches. (sc1.checkpoint.com)

• “Local Breakout routes take precedence over Static routes / Dynamic routes” (especially important when using VTIs / route-based VPN). (sc1.checkpoint.com)

2.2 Non-negotiable rule design constraints (Local Breakout and Backhaul)

In rules with Local Breakout behavior:

• Do not use Any in Destination.

• Do not use destination objects that can match non-Internet traffic, such as:

  • inter-VLAN traffic

  • traffic to next-hop gateways

  • DMZ network traffic
    Reason: you can inadvertently send internal/enterprise traffic directly to ISPs in cleartext. (sc1.checkpoint.com)

In rules with Backhaul behavior (branch → center → internet):

• Same guidance: avoid Any and avoid objects that may match non-Internet traffic; otherwise you risk mis-steering and unintended internet egress. (sc1.checkpoint.com)

2.3 Overlay vs Breakout ordering (the rulebase must reflect encryption intent)

Always place Overlay rules above Local Breakout rules.
Why: if VPN traffic matches a breakout rule, SD-WAN can disable encryption by design and route traffic to ISP as cleartext. This failure mode is explicitly documented in troubleshooting guidance. (sc1.checkpoint.com)

2.4 “Do not use the Internet object” — interpret correctly

Check Point notes that generic “Internet” objects cannot reliably differentiate:

• true Internet traffic,

• Overlay traffic,

• or cleartext traffic routed via MPLS next hop. (sc1.checkpoint.com)

Instead, prefer the SD-WAN-specific constructs described below (Dynamic Objects / SD-WAN Internet).

3) Dynamic Objects and version prerequisites: use the right abstraction for “Internet” and “VPN domains”

3.1 Why Dynamic Objects matter

Dynamic Objects were introduced to better represent:

• Overlay address spaces (VPN domains, peers, public subnets inside encryption domains)

• Internet ranges, while excluding reserved ranges and local interface-connected networks (sc1.checkpoint.com)

This materially reduces the need for “manual bypass rules” and prevents common misclassification scenarios.

3.2 What each Dynamic Object means (operationally)

• My VPN Domain: represents the local encryption domain and also the external interface used to establish S2S tunnels; it matches traffic between VPN peers (including overlay probing). (sc1.checkpoint.com)

• Peer VPN Domain: represents the aggregated encryption domain of all SD-WAN VPN peers; also matches traffic between peers (including overlay probing). (sc1.checkpoint.com)

• SD-WAN Internet: represents public Internet ranges while excluding reserved ranges and IPs of networks directly connected to the gateway (plus other exclusions documented). (sc1.checkpoint.com)

3.3 Version support (don’t guess—validate)

Dynamic Objects were introduced in later trains/hotfix levels (for example, R81.20 Jumbo Take 79 notes them explicitly). (sc1.checkpoint.com)
For R82, similar enablement is referenced in Jumbo documentation. (sc1.checkpoint.com)

Best practice: treat “Dynamic Objects availability” as a compatibility gate in your rollout checklist.

4) Rule semantics by behavior type (what the gateway actually does)

4.1 Rule with “Overlay” behavior

• If traffic must be encrypted and the peer is also SD-WAN-enabled: routing is based on the SD-WAN steering behavior. (sc1.checkpoint.com)

• If traffic must be encrypted and the peer is not SD-WAN: routing follows Link Selection configured in SmartConsole. (sc1.checkpoint.com)

• If traffic does not need encryption: traffic follows OS routing table. (sc1.checkpoint.com)

4.2 Rule with “Local Breakout” behavior

• Ensure Overlay traffic does not match Local Breakout; otherwise, VPN cannot leverage all VPN Transports/WAN Links to reach the SD-WAN peer (and you risk cleartext routing). (sc1.checkpoint.com)

• Ensure only true outbound Internet traffic matches breakout.

4.3 Rule with “Backhaul” behavior

• Branch encrypts traffic and sends it to the Center gateway over S2S VPN.

• Center then sends that traffic to the Internet as Local Breakout. (sc1.checkpoint.com)

5) Probing best practices: build SLA measurement that cannot be “accidentally blocked”

5.1 Overlay Probing mechanics (what’s measured and how)

Overlay probing measures SLA over SD-WAN Overlay Transports using ICMP Echo Requests sent between SD-WAN interfaces on local and remote peers. (sc1.checkpoint.com)

5.2 The asymmetric reality (and why your policy must account for it)

• The gateway sends ICMP Echo Requests regardless of SD-WAN Policy rules (it originates probing via the relevant VPN interface).

• But it receives ICMP Echo Replies based on SD-WAN Policy matching. (sc1.checkpoint.com)

That means this asymmetric condition is possible (documented):

• GW1 sends Echo Requests via ISP1→ISP1 to GW2

• GW2 replies via ISP2→ISP1 back to GW1 (sc1.checkpoint.com)

Implication: if your policy doesn’t catch replies correctly (Overlay behavior match), your SLA measurements become unreliable and steering decisions degrade.

5.3 Best practice: ensure probing matches an Overlay rule

Check Point’s guidance: probing over overlay must match a rule with Overlay behavior, including all real IPs of SD-WAN interfaces in Source/Destination (NATed IPs are not required in the common guidance). (sc1.checkpoint.com)

5.4 Use the Wizard defaults—then harden intentionally

The SD-WAN Wizard creates default rules using Dynamic Objects (e.g., My VPN Domain / Peer VPN Domain, SD-WAN Internet) to automatically match overlay traffic and probing, reducing manual “special-case” rules. (sc1.checkpoint.com)

If you do not use the Wizard (manual deployments), Check Point states you must create the required overlay “catch-all / clean up” rule to capture overlay traffic including probing. (sc1.checkpoint.com)

6) Operational checklist (what to validate before go-live)

VPN / Link Selection

• Link Selection configured in each gateway object (fallback when SD-WAN service is down). (sc1.checkpoint.com)

• WAN Link Mapping consistent across SD-WAN peers. (sc1.checkpoint.com)

SD-WAN Policy hygiene

• Overlay rules above Breakout rules. (sc1.checkpoint.com)

• No Any Destination in Breakout/Backhaul rules; destinations must be Internet-scoped. (sc1.checkpoint.com)

• Prefer Dynamic Objects (My VPN Domain / Peer VPN Domain / SD-WAN Internet) when supported. (sc1.checkpoint.com)

Probing and SLA integrity

• Ensure overlay probing traffic is matched by Overlay behavior rules (especially replies). (sc1.checkpoint.com)

• If using route-based VPN / VTIs, explicitly avoid breakout matching for traffic that should be encrypted (breakout takes precedence over routes). (sc1.checkpoint.com)

7) Troubleshooting signals that confirm misclassification

If you see behavior like “VPN traffic goes cleartext” or “overlay SLA looks wrong,” Check Point documents kernel debug patterns and root cause: traffic is matching a Local Breakout rule which disables VPN encryption. (sc1.checkpoint.com)