NSE7 Part 10: Designing SD-WAN Rules and Routing

16 August 2026 NSE7 Fortinet

Parts 8 and 9 built the routing table. This post is where that routing table actually gets used, or overridden, by SD-WAN’s own rule and routing logic. This is the densest single post in the series, because the blueprint bundles two separate tasks here, designing SD-WAN rules and configuring SD-WAN routing, and the two are inseparable in practice: a rule can only steer traffic across paths the routing layer underneath it actually makes available.

User-Defined SD-WAN Rules

An SD-WAN rule (config system sdwan → config service) matches traffic against criteria and selects a member or set of members to carry it, evaluated top-down against the first rule that matches, same evaluation order discipline as ordinary firewall policy.

config system sdwan
    config service
        edit 1
            set name "voice-lowest-latency"
            set mode sla
            set dst "voice-subnets"
            set sla-target
                edit 1
                    set health-check "hub1-sla"
                    set latency-threshold 50
                    set jitter-threshold 20
                next
            end
            set priority-members "mpls" "broadband1"
        next
    end
end

The SD-WAN Rule Lookup Process

Rules evaluate in configured order, and the first rule whose match criteria (source, destination, application, internet service, or a combination) are satisfied wins, with its configured strategy then determining member selection. This is the same principle as firewall policy ordering, and the same failure mode applies: a broadly-matching rule placed above a more specific one will shadow it entirely, and traffic intended for the specific rule never reaches it. Rule order review is a standard part of any SD-WAN troubleshooting session for exactly this reason, and diagnose sys sdwan service (introduced in Part 5) is the direct way to confirm which rule and member a given flow actually matched, rather than reasoning through rule order by eye.

SD-WAN for Local-Out Traffic

Local-out traffic, originating from the FortiGate itself rather than transiting it, follows its own path through SD-WAN rule evaluation, and needs explicit handling if it’s meant to be steered the same way transit traffic is. set src-addr-local in an SD-WAN rule, or a rule specifically scoped to a local-out use case (FortiGuard queries, NTP, SNMP traps to a monitoring host over a specific WAN member), is how a design ensures the FortiGate’s own management traffic follows the intended path rather than falling through to whatever the implicit rule below selects by default.

The Implicit SD-WAN Rule

Every SD-WAN zone has an implicit rule beneath every user-defined rule: any traffic that doesn’t match a configured rule still needs to go somewhere, and the implicit rule handles it using the zone’s default load-balancing strategy across all its members (source-IP-based by default, distributing sessions across members without any of the health-aware, application-aware logic a user-defined rule provides). The exam-relevant point: the implicit rule is not a fallback to avoid at all costs, it’s a legitimate design safety net, but traffic riding on it gets none of the deliberate steering logic a design actually cares about, so a well-designed rule set should leave as little traffic falling through to the implicit rule as the requirements genuinely allow, and any traffic that does legitimately fall through should be traffic where indifferent load-balancing is actually an acceptable outcome.

Monitoring SD-WAN Rule Status

Already covered mechanically in Part 5 (diagnose sys sdwan service, the SD-WAN monitor widget); worth restating here in the rules context specifically: the live rule status view shows not just which member a rule currently selects, but whether that selection is because the preferred member is healthy, or because it’s failed over to a lower-priority member due to an SLA breach. Distinguishing “this rule is working as designed” from “this rule is currently in a degraded fallback state that happens to still be passing traffic” is a real operational skill this monitoring surface exists to support, and a design that only checks whether traffic is flowing, without checking which member it’s actually flowing over, can miss a circuit that’s been silently degraded for hours.

SD-WAN Rule Strategies

Four strategy modes, each answering a different steering question:

Manual: a fixed, ordered member list; no health-awareness at all beyond removing a fully-down member from the list.
Best Quality: continuously selects whichever available member currently measures best against a configured SLA metric (latency, jitter, packet loss, or a combined quality score), reevaluating as conditions change.
Lowest Cost (SLA): the mode used in the example above: among members that currently meet the configured SLA thresholds, select the lowest-cost (highest-priority) one; a member failing SLA drops out of consideration entirely until it recovers, rather than merely being deprioritized.
Maximize Bandwidth (SLA): load-balances traffic across every member that currently meets SLA thresholds, rather than concentrating traffic on a single best or lowest-cost member, useful for bulk-transfer traffic classes where aggregate throughput matters more than any single path’s individual quality.

Preferred Member Election and Priority Advantage

Within Lowest Cost (SLA) specifically, member priority acts as a tiebreaker and a bias: among members that all currently pass SLA thresholds, the higher-priority member is preferred even if a lower-priority member happens to be measuring marginally better on the SLA metric at that instant. This prevents constant flapping between two roughly-equivalent members chasing tiny, insignificant SLA measurement differences, at the cost of not always picking the single objectively best-measuring path in every instant. This is a deliberate design tradeoff, not an oversight, and the exam treats understanding why priority advantage exists (stability over marginal optimality) as more important than just knowing the setting exists.

SD-WAN Rule Traffic Matching Criteria

Beyond ordinary source/destination/service matching, SD-WAN rules support application and internet service (ISDB) matching, which is what makes application-aware steering possible at all.

Application Steering and the Learning Phase

Application-based SD-WAN rules match on FortiOS’s application signature database, the same engine backing application control security profiles. New sessions are provisionally routed while application identification is still in progress, since application signatures for many protocols require several packets of payload before a confident match, and once identification completes, FortiOS can reevaluate the session against SD-WAN rules and, if a better-matching rule now applies, move the session to a different member mid-flow. This application learning phase is a specific, testable behavior: a session’s first few packets may legitimately traverse a different member than its later packets once application ID resolves, which is expected behavior, not a bug, and a design relying on absolutely consistent per-session path selection from the very first packet needs to account for this rather than assume application-based rules behave identically to source/destination-based ones from packet one.

Internet Services as Destination Criteria

ISDB (Internet Service Database) matching lets a rule reference a maintained, Fortinet-curated object representing a specific cloud service or SaaS provider (by its actual published IP ranges) rather than an admin manually maintaining an address group of a provider’s IPs, which change over time without notice. A rule matching “Internet Service: Microsoft_365” steers traffic toward that service specifically, and Fortinet’s own ISDB updates keep the underlying IP set current without any admin intervention. This is the mechanism underneath the selective-DIA pattern from Part 5: a design that wants to break out specific well-known SaaS traffic locally while backhauling everything else typically expresses “specific well-known SaaS” as ISDB matches rather than hand-maintained address objects.

Key Routing Principles in SD-WAN

The section the blueprint’s “Configure SD-WAN routing” task is actually built around, and the part most likely to be misunderstood by anyone who’s only worked with SD-WAN rules and never had to reason about what’s underneath them: SD-WAN rules operate on top of policy routing, not instead of ordinary routing. A rule selects a member; the actual forwarding decision for that traffic still involves the routing table, policy routes, and the session table, in a specific order.

Policy Routes and the Route Lookup Process

FortiOS evaluates policy routes (config router policy) before the standard routing table for matching traffic, and SD-WAN’s own rule mechanism is implemented as a specific, internally-managed category of policy route rather than a separate parallel mechanism. The practical route lookup order for a new session: policy route match (including SD-WAN’s own internally-generated policy routes for its rules) first, standard routing table (including OSPF/BGP-learned routes from Parts 8 and 9) as the fallback when no policy route matches.

Member Static Routes and Static Routes for Zones

Each SD-WAN member typically has its own static default or specific route toward its next hop, configured either as an ordinary static route referencing that member’s interface, or, in newer FortiOS versions, as a zone-level static route applied once across every member in a zone rather than repeated per-member. The distinction matters operationally: a zone-level route simplifies configuration for a zone whose members all genuinely share the same next-hop logic (unusual for a physical WAN zone, more common for a zone of IPsec tunnel members all terminating logically toward the same hub), while per-member static routes remain necessary wherever members genuinely need distinct next hops (the normal case for physically distinct WAN circuits with different ISP-assigned gateways).

Member Probe Routes

The routes SD-WAN’s own health-check probes use to actually reach their SLA targets are a distinct concern from the routes carrying real traffic, and can, in some designs, deliberately differ, a probe route ensuring health-check traffic always exits via a specific member even if real traffic for that destination would otherwise be steered elsewhere by a rule, so that SLA measurement for a given member reflects that member’s own health rather than being contaminated by whatever path a rule happened to pick for probe-matching traffic.

Session Tables and SD-WAN

Different Protocol States and Common Session Flags

FortiOS’s session table tracks protocol-specific state (TCP handshake state, UDP pseudo-state, ICMP) alongside a set of session flags relevant specifically to SD-WAN-steered sessions, visible via diagnose sys session list or filtered lookups against a specific session. A session flag indicating it was steered by a specific SD-WAN rule and is currently pinned to a specific member is the mechanism that keeps a session’s return traffic and subsequent packets consistent with wherever the session’s first packet was steered, rather than every packet independently re-evaluating SD-WAN rules.

Session Reevaluation and Triggers

A session, once established and pinned to a member, does not silently migrate to a different member just because that member’s SLA measurement changes moment to moment, session pinning exists specifically to avoid mid-session path changes disrupting stateful protocols. Reevaluation happens at specific triggers: a member going fully down (forcing existing sessions on it to fail over), the application learning phase completing (covered above, a legitimate mid-session member change), or specific configuration changes that FortiOS treats as requiring a fresh rule evaluation. Absent one of those triggers, an established session rides its originally-selected member for its full lifetime even if a “better” member becomes available partway through.

Routing Changes in SNAT Sessions

Source NAT sessions carry an additional constraint worth naming explicitly: a session’s SNAT translation (the specific IP and port chosen from a NAT pool or interface-IP NAT) is bound to the original egress interface/member at session creation. A mid-session member change for a NATed session isn’t just a routing change, it potentially invalidates the existing NAT binding entirely, since the new egress member may have an entirely different public IP. This is part of why session pinning matters more, not less, for NATed traffic than for traffic that isn’t translated at all, and it’s a specific, testable interaction between two features (SD-WAN steering, NAT) that are each individually simple but combine into a genuinely more constrained behavior than either alone would suggest.

Routing Considerations: Choosing What to Actually Run

The blueprint’s own framing for this task, “determining which type of routing and routing protocols to use,” is the design-judgment capstone this whole post has been building toward. A small, largely-static hub-and-spoke design with a handful of spokes and no dynamic shortcut requirements can reasonably run static routes plus SD-WAN rules with no dynamic routing protocol at all. A larger design needing automatic failover awareness, redistribution between sites, or ADVPN’s dynamic shortcut tunnels needs BGP (occasionally OSPF, per Part 8’s narrower use case) underneath the SD-WAN layer, not instead of it. Getting this choice right, and being able to justify it against a described topology and its actual requirements rather than defaulting to “just run BGP everywhere,” is what separates a passing scenario-question answer from a technically-correct-but-overcomplicated one.

Part 11 takes routing and applies it to the tunnel layer directly: advanced IPsec design at the scale multihub and multiregion deployments actually need.