FortiGate SD-WAN with Performance SLA

The one-sentence mental model

SD-WAN on a FortiGate turns “which WAN link do I send this out?” from a routing decision into an application-aware, SLA-aware policy decision. Instead of your MPLS being preferred until it’s dead, it’s preferred until it stops meeting the SLA — which might be before it’s dead.

The three pieces

1. SD-WAN zone + members

You group physical WAN interfaces into one logical SD-WAN zone:

config system sdwan
  set status enable
  config zone
    edit "virtual-wan"
    next
  end
  config members
    edit 1
      set interface "wan1"    # MPLS
      set gateway 203.0.113.1
      set zone "virtual-wan"
    next
    edit 2
      set interface "wan2"    # Broadband
      set gateway 198.51.100.1
      set zone "virtual-wan"
    next
    edit 3
      set interface "wan3"    # LTE
      set gateway 192.0.2.1
      set zone "virtual-wan"
    next
  end
end

Firewall policies now use “virtual-wan” as the outgoing interface — you never pick wan1/wan2/wan3 directly.

2. Performance SLA (health check)

The SLA object continuously probes each member and measures latency, jitter, and packet loss:

config system sdwan
  config health-check
    edit "google-dns"
      set server "8.8.8.8"
      set protocol ping           # or http/twamp/dns
      set members 1 2 3
      set interval 500            # 500 ms probes
      set failtime 5              # 5 missed = down
      set recoverytime 10
      config sla
        edit 1
          set latency-threshold 100
          set jitter-threshold 20
          set packetloss-threshold 5
        next
      end
    next
  end
end

Result: each member is tagged “meeting SLA” or “failing SLA” at any moment, live.

3. SD-WAN rules

Rules bind traffic (source/dest/service/app) to an SLA-aware preference:

config system sdwan
  config service
    edit 1
      set name "voip-over-best-latency"
      set mode sla
      set health-check "google-dns"
      set sla 1
      set src "all"
      set dst "voip-network"
      set service "SIP"
      set priority-members 1 2 3   # try wan1, then wan2, then wan3
    next
    edit 2
      set name "backup-traffic-on-cheapest"
      set mode manual
      set src "backup-servers"
      set dst "cloud-backup"
      set priority-members 2       # broadband only
    next
  end
end

Rules are top-down first-match — same as firewall policies.

How failover actually works

The classic failover mistake is thinking SD-WAN failover = link-down failover. It’s not.

• Every 500 ms (or whatever probe interval), the SLA object retests each member.
• If wan1’s latency climbs above 100 ms, the SLA object marks it failing SLA — even though the link is up.
• Any SD-WAN rule with mode sla immediately excludes wan1 from its member list.
• The traffic moves to the next preferred member that is meeting SLA.
• When wan1 recovers (holds SLA for recoverytime probes), it’s re-added to the pool.

This is why SD-WAN beats classic dual-WAN with floating statics: it reacts to quality degradation, not just link failure.

Modes on the SD-WAN rule

Mode	Behavior
manual	Send to a specific member. No failover unless that member is dead.
best-quality	Compare SLA metrics across members, pick the best right now.
lowest-cost (SLA)	Prefer cheapest member that is still meeting SLA. Only leave cheap when it fails SLA.
maximize-bandwidth (load-balance)	Load-balance across members meeting SLA.
priority	Ordered member list — first meeting SLA wins.

Lowest-cost (SLA) is the mode you’ll see most in production — “prefer broadband while it’s good, fall back to MPLS only when broadband degrades.”

Combining with routing

SD-WAN sits on top of the routing table. You still need routes (static defaults, BGP peers, OSPF neighbors) to know how to reach the far end via each member. SD-WAN just picks the member out of the equal-cost paths.

For hub-and-spoke SD-WAN VPNs, an IPsec tunnel per member is standard: wan1 ↔ hub-tunnel1, wan2 ↔ hub-tunnel2. Both tunnels are equal-cost. SD-WAN rules pick the better one per flow.

Common exam / real-world mistakes

1. Forgetting the health-check server can itself be down. Probing 8.8.8.8 works — until Google has a bad day. Better: probe an FQDN you control, or use twamp with a FortiGate at the hub as responder.
2. Setting SLA thresholds too tight. 100 ms latency threshold on a satellite backup will constantly mark it failing. Match thresholds to the app: 150 ms for voice, 300 ms for file transfer.
3. Not using zones in firewall policies. If a policy still references wan1 directly, SD-WAN can’t redirect it. Every outbound policy needs to use the SD-WAN zone as outgoing interface.
4. Ignoring per-app awareness. Modes like best-quality are per-flow, but you can also key rules on application signatures (e.g., “all Office 365 → best-quality”). This is the modern approach.
5. Missing that manual mode doesn’t do SLA failover. If you set mode manual and the manual member fails SLA, traffic keeps hitting it. Only mode sla and mode priority react to SLA.

Cheat strip

Zone       group of WAN members (used as outgoing interface in policies)
Members    physical WANs with gateway + zone binding
SLA        health-check → latency + jitter + loss thresholds
Rules      top-down first-match. mode = sla | best-quality | manual | ...
Failover   triggered by SLA breach, not just link down
Recovery   member holds SLA for recoverytime probes → re-added

Common mode:  lowest-cost (SLA)  — cheap link until it degrades
Voice mode:   best-quality        — always pick the best latency/jitter
Backup mode:  manual              — pin heavy traffic to a specific link