Quantum SD-WAN (Check Point) — Deeper Technical View of Steering, Policy Matching, and Enforcement

[WiliRGasparetto]

Quantum SD-WAN (Check Point) — Deeper Technical View of Steering, Policy Matching, and Enforcement

Quantum SD-WAN is often introduced as “dynamic WAN link selection.” Technically, it’s closer to a policy-controlled, measurement-driven path selection engine that influences per-connection egress and VPN transport—without requiring dynamic routing for the decision itself.

Below is a more technical  walkthrough: what is computed, what is installed, what is enforced, and why “policy looks right” can still produce unexpected paths.

1) What Quantum SD-WAN does (technical thesis)

Quantum SD-WAN enables a Security Gateway / Cluster to select an egress ISP interface or VPN transport per connection based on:

• Classification (source/destination/identity + service/application)

• Measured link quality (latency/jitter/loss, optionally utilization)

• Rule steering intent (prioritization / link aggregation / breakout vs overlay/backhaul)

What it is not: a replacement for routing protocols. Routing still provides reachability; SD-WAN provides path selection logic layered on top of reachability.

Operational implication: you don’t “route to ISP1/ISP2”; you steer sessions to a link/transport chosen by the SD-WAN engine.

2) Control plane vs data plane (what owns what)

A useful separation:

Control plane (steering decision + state distribution)

• SD-WAN policy definition (Infinity Portal)

• WAN link objects, thresholds, measurement targets

• SD-WAN steering computation (probes → eligibility → selection)

• Installation of steering state for enforcement (tables/state on the gateway)

• Telemetry/event publication (iNext/Nano + cpview)

Data plane (packet forwarding + VPN encapsulation)

• Connection setup and forwarding decisions

• NAT, access control, IPS/Threat Prevention enforcement

• VPN encapsulation and transport selection for overlay/backhaul

• Failover behavior at runtime (within allowed/preferred sets)

Key rule: SD-WAN steering decisions are only applied after Security Policy allows the traffic. SD-WAN cannot “force” a denied flow to go out a different ISP.

3) Simple use case (but with the missing details)

Two ISPs at a branch:

• Zoom → ISP #1

• Microsoft 365 → ISP #2

What’s happening under the hood is not “PBR in the classical sense,” but:

• session classification (app/service/identity)

• link health evaluation against thresholds

• selection of eligible ISP(s)

• installation of that choice so the connection setup pipeline uses the correct egress interface

If a failover happens and your policy uses aggregation, per-flow path choice can change due to hashing, even with the same rule.

4) SD-WAN actions (Breakout vs Overlay vs Backhaul) — deeper technical split

A) Local Breakout (Internet egress steering)

• Goal: choose the best ISP interface for direct Internet traffic.

• Enforcement point: firewall connection handling chooses a WAN interface based on steering state.

Common failure pattern: app classification ambiguity → wrong rule match → wrong ISP.

B) Overlay (VPN steering between peers)

• Goal: for each VPN peer pair, select the best VPN transport (underlay link/interface) to carry encrypted traffic.

• Enforcement point: VPN subsystem chooses the transport for the tunnel/session based on steering state.

Common failure pattern: peers/transport eligibility not installed correctly → VPN uses a default or “last known good” path.

C) Backhaul (branch Internet via HQ over VPN)

• Composite pipeline:

  • Branch → HQ: overlay transport selection (VPN)

  • HQ → Internet: breakout selection (ISP egress)

• Troubleshooting must split both legs. People often debug only one side.

5) SD-WAN Policy matching (the real classification mechanics)

An SD-WAN policy is an ordered rulebase. Each connection is evaluated against:

5.1 Source/Destination dimensions

• IP address / network objects

• Identity (User / Computer Identity)

• Destination objects (including Updatable Objects)

5.2 Service/Application dimensions

• Service ports (HTTPS, FTP, etc.)

• Application signatures (e.g., Zoom/Teams categories, depending on what is supported and enabled)

5.3 The “first packet problem”

A critical nuance: application identification on the first packet is not always deterministic.
Examples:

• multiple SaaS apps behind the same IP/CDN

• TLS where SNI is missing/obfuscated early

• traffic patterns that require more packets for confident classification

Why this matters: steering is ideally decided at/near connection setup; if classification matures later, you can see:

• initial steering based on coarse match (destination/service)

• then “it looks like the app is X” but the session is already pinned to an ISP/transport

Best practice (technical reasoning): use Updatable Objects in Destination whenever possible. This increases the chance that the rule matches accurately early (even when application classification is ambiguous).

6) Steering behavior objects (what a rule really controls)

A steering rule is not just “send app X to ISP Y.” It defines:

1. Measurement targets
   What is probed to represent “Internet quality” or “reachability” per link.

2. Quality criteria + thresholds
   Latency, jitter, loss (and potentially utilization) thresholds that determine link eligibility.

3. Selection method

   • Prioritization: pick the best/priority candidate among eligible links/transports

   • Link aggregation: mark multiple candidates as eligible; per-flow selection may be done by hashing/aggregation method

Important: eligibility comes first. If all links fail thresholds, the result can be “no eligible ISP/transport,” which is often misread as “SD-WAN is broken” when it is behaving correctly.

7) Steering criteria (deeper look)

Latency / jitter / loss

• Typically measured via active probing (quality check) to one or more targets.

• Decision is per rule: different apps can have different thresholds.

WAN utilization (when used)

• Adds a capacity dimension: a link could be “healthy” but saturated, so it becomes less preferred.

• This is often where teams need to align with business intent: latency-sensitive apps vs bulk traffic.

Quality Check configuration (where mistakes happen)

Even with a perfect policy, poor probing design causes bad decisions:

• probing targets not representative (e.g., a single target that’s sometimes rate-limited)

• too infrequent probing → slow reaction

• too aggressive probing → noise/false degradation

• thresholds that don’t match realistic ISP behavior

8)Enablement workflow (what must exist where) — more explicit

To have deterministic steering, you need consistency across four planes:

8.1 Gateway / Cluster members

• SD-WAN interfaces configured consistently on all members

• correct WAN link binding (interface mapping)

• Nano Agent + SD-WAN services healthy (where applicable)

• consistent reachability (routing) for probe targets and peer endpoints

8.2 SmartConsole / Security Policy

• Access Control must allow the traffic that you expect SD-WAN to steer

• NAT rules must not accidentally “force” an egress path (e.g., implicit NAT assumptions)

• VPN domain/topology must align with overlay/backhaul design

8.3 Smart-1 Cloud (objects/management integration)

• objects exist and are synchronized correctly (depending on architecture)

8.4 Infinity Portal (SD-WAN policy plane)

• WAN links, thresholds, measurement targets

• SD-WAN Policy ordering and steering objects

• consistent gateway membership / profile assignment

Takeaway: “policy is correct” is meaningless unless:

• the gateway installed it

• probing data exists

• steering state is installed and consumed by enforcement

9) Practical validation checklist (technical, not UI-based)

When you get “wrong ISP / wrong overlay path,” validate in this order:

1. Traffic classification

   • What rule is actually matching (source/dest/service/app/identity)?

   • Is first-packet ambiguity likely?

2. Probing and thresholds

   • Do you have current probe results for the relevant decision?

   • Are links eligible under the rule thresholds?

3. Selection mode

   • Prioritization vs link aggregation changes expectations.

   • With aggregation, per-flow hash choice can look “random” to operators.

4. Enforcement pipeline alignment

   • Breakout: FW chooses ISP from steering state

   • Overlay/backhaul: VPN chooses transport from steering state

5. State/telemetry consistency

   • Portal events (iNext/Nano) should align with gateway telemetry (cpview) and observed behavior.

10) Common pitfalls (why steering “looks wrong”)

• Thresholds too strict → all links disallowed → fallback behavior or failure

• Single probe target bias → false positives/negatives on link health

• Rule ordering mistakes → coarse rule matches before specific one

• Application detection timing → session pinned before app becomes known

• Aggregation misunderstanding → multiple links eligible, hash decides per-flow

• Backhaul confusion → people troubleshoot HQ egress while the problem is branch→HQ overlay (or vice-versa)

Fontes: Quantum SD-WAN - Technical | eLearning https://checkpointpartners.litmoseu.com/course/1588097 , 

Admin Guide:  https://support.checkpoint.com/results/sk/sk180605

Demo Point: SD-WAN https://usercenter.checkpoint.com/ucapps/techpoint/demo-point

[murilomuinhos]

Excellent post, I got a great overview of the subject! I had already studied other SD-WAN solutions and was just looking for a summary to make a comparison!

[WiliRGasparetto]

Thank you, Murilo  I’m glad I could help with your SD-WAN studies. I’ll be publishing an implementation guide soon as well.

[the_rock]

Man, wow...AMAZING job!

[WiliRGasparetto]

Thank you,  Andy

[the_rock]

Keep 'em coming.

[WiliRGasparetto]

I'll definitely do that.

[the_rock]

I see new MVP member in near tuture...just saying 😉

[WiliRGasparetto]

Amen, we are working on it.

[Dom_Galvao]

Excellent for studying, provides clear and objective examples, very good, keep providing us with quality materials.

[PedroRFernandes]

Well done, @WiliRGasparetto!

[Pedro139128]

Well done, @WiliRGasparetto!