01The core distinction: underlay vs overlay
The ISP links carry packets, so it's tempting to call them "the SD-WAN." But SD-WAN doesn't run on the ISP — it runs on a logical network layered over it. The ISP gives you reachability; the overlay gives you a stable, private topology that looks the same no matter which transport is underneath.
SD-WAN OVERLAY
┌──────────────────────────────┐
│ Logical VPN network │
│ │
│ Site A ═══════════ Site B │
└──────────┬───────────┬───────┘
│ │
IPsec VPN IPsec VPN
│ │
─────┘ └─────
ISP 1 ISP 2
Underlay Underlay
So the answer to "is the overlay my ISP links?" is: no — the ISP links are the reason you build an overlay, but they are not the overlay. The overlay is the tunnel mesh riding on top of them.
SD-WAN overlay = underlay transports + tunnels (IPsec/VXLAN) + SD-WAN rules
02Worked example: two ISPs per site
Give each of two sites a pair of internet circuits and build an IPsec tunnel over each:
Site A Site B
FortiGate FortiGate
│ │
├── ISP1 ───────────────────────┤
│ IPsec tunnel 1 │
│ │
└── ISP2 ───────────────────────┘
IPsec tunnel 2
Name the pieces and the layering is obvious:
| Underlay 1 | ISP1 / Internet — raw reachability. |
|---|---|
| Underlay 2 | ISP2 / Internet — raw reachability. |
| Overlay 1 | IPsec tunnel over ISP1. |
| Overlay 2 | IPsec tunnel over ISP2. |
| SD-WAN | Chooses between Overlay 1 and Overlay 2 per rule/SLA. |
Two ISPs became two underlays, two overlays, and one decision layer. SD-WAN never picks "ISP1" — it picks Overlay 1, which happens to ride ISP1 today.
03The three layers: reachability, topology, decision
Every SD-WAN design is these three responsibilities, kept separate:
| Underlay — connectivity | The transports that move packets: ISP1, ISP2, MPLS, LTE, 5G. "Can I reach the other end at all?" |
|---|---|
| Overlay — logical connectivity | The tunnels that form your private topology: IPsec, GRE, VXLAN. "What does my network look like, regardless of transport?" |
| SD-WAN — decision / control | The rules and SLA probes that steer traffic: "Which path should this application use right now?" |
Read them top to bottom and each layer only needs the one below it. The overlay doesn't care how reachability happens; SD-WAN doesn't care how the topology is built — it just picks among available paths.
SD-WAN path = reachability (underlay) + logical topology (overlay) + decision (SLA rules)
04Why build an overlay at all
The payoff is a consistent logical network despite different transports. Sites keep the same addressing and adjacencies whether a link is fibre, LTE, or a different ISP next month — and SD-WAN can measure each path continuously and move traffic when quality drops.
OVERLAY
Site A ═════════════════ Site B
10.0.0.0/8
│
┌────────┴────────┐
│ │
ISP 1 ISP 2
18 ms 35 ms
0% loss 2% loss
SD-WAN continuously measures latency, jitter, packet loss and availability, then steers per application:
| VoIP / real-time | Overlay → ISP1 (18 ms, 0% loss) — loss and jitter sensitive. |
|---|---|
| Web / bulk | Overlay → ISP2 (35 ms, 2% loss) — tolerant, keeps ISP1 clear. |
Same logical link, two physical paths, a live quality-based choice. That is the whole reason the overlay exists — it gives SD-WAN something stable to steer over.
05Organize zones by role, not by ISP
Now the practical question. The tempting-but-wrong instinct is "ISP1 = SD-WAN zone 1, ISP2 = SD-WAN zone 2." That mirrors the physical circuits, not what you actually steer. The useful question is: what type of connectivity does this interface provide?
FORTIGATE
│
SD-WAN
│
┌───────────┴───────────┐
│ │
UNDERLAY OVERLAY
(internet) (private VPN)
│ │
┌─────┴─────┐ ┌─────┴─────┐
│ │ │ │
ISP1 ISP2 IPsec-1 IPsec-2
Group interfaces by the role they play — direct internet vs. private overlay — so your SD-WAN rules can speak in intent ("send corporate traffic over the overlay") instead of naming circuits. One zone per ISP can't express that; a zone per role can.
06The layout that works: overlay vs internet
For a typical branch with two ISPs and an IPsec/ADVPN overlay to the hub, two zones do the job:
Zone overlay | Members: IPsec-HUB-ISP1, IPsec-HUB-ISP2. Purpose: Branch ↔ HQ, Branch ↔ Branch, private corporate traffic (ERP, AD, file shares). |
|---|---|
Zone internet | Members: wan1, wan2. Purpose: Direct internet breakout, SaaS, Microsoft 365, cloud services. |
On a FortiGate that is two zones and their members:
config system sdwan
set status enable
config zone
edit "overlay"
next
edit "internet"
next
end
config members
edit 1
set interface "IPsec-HUB-ISP1"
set zone "overlay"
next
edit 2
set interface "IPsec-HUB-ISP2"
set zone "overlay"
next
edit 3
set interface "wan1"
set zone "internet"
next
edit 4
set interface "wan2"
set zone "internet"
next
end
end
Now rules read as intent, and SD-WAN still load-balances/fails-over within the chosen zone:
| Corporate ERP | src Branch-LAN → dst HQ-LAN, service ERP → zone overlay. SD-WAN picks IPsec-ISP1 or IPsec-ISP2 by SLA — corporate traffic never leaks straight to the internet. |
|---|---|
| Microsoft 365 | src Branch-LAN → dst Internet, service HTTPS → zone internet. SD-WAN picks wan1 or wan2 — local breakout, no hairpin through the hub. |
Add an mpls zone if you have a private WAN circuit too — same idea, one zone per
transport role. Each member is a tunnel-plus-circuit pairing:
SD-WAN member = IPsec tunnel + underlay interface (WAN)
07ADVPN: the overlay ignores the transport
This is where the split earns its keep. In a Fortinet hub-and-spoke, each spoke builds overlay tunnels to the hub over every WAN. ADVPN then lets two spokes negotiate a dynamic shortcut directly, on demand:
HUB
┌────┴────┐
IPsec IPsec
/ \
Spoke A ═════════ Spoke B
shortcut
│ │
ISP1/ISP2 ISP1/ISP2
The shortcut is an overlay adjacency between Spoke A and Spoke B. The underlay beneath it might actually be Spoke A ISP1 → Internet → Spoke B ISP2 — different circuits on each end, and neither spoke cares. That is the whole point:
Overlay adjacency = logical (stable) ≠ underlay path (whatever gets there)
Because the overlay is decoupled from the transport, ADVPN can spin up a spoke-to-spoke path without pre-provisioned tunnels, and SD-WAN can still SLA-steer it like any other overlay member.
08Troubleshoot the stack & where to go next
When something breaks, walk the same layering top-down. Each level depends only on the one below, so the hierarchy is your fault tree:
SD-WAN zone → member → IPsec tunnel → underlay interface (WAN)
- Zone / rule — is traffic matching the SD-WAN rule and landing in the right zone?
- Member / SLA — is the member alive, and does its health-check meet the SLA?
- IPsec tunnel — is the overlay tunnel up (Phase 1/2)?
- Underlay — is the WAN interface actually reaching the peer?
The SLA probes make the "member" layer measurable — this is the command that ties back to §04's steering:
diagnose sys sdwan health-check
Health Check(HQ-probe): Seq(1 IPsec-HUB-ISP1): state(alive), packet-loss(0.000%) latency(18.412), jitter(1.204), mos(4.38) Seq(2 IPsec-HUB-ISP2): state(alive), packet-loss(2.100%) latency(34.905), jitter(3.870), mos(4.11)
The two sequences are the two overlay members; the loss/latency/jitter figures are why
SD-WAN prefers one over the other. If a member reads dead, drop a level — check the
IPsec tunnel, then the underlay interface it rides.
From here the natural follow-ons are SD-WAN rules and strategies (best-quality vs. lowest-cost vs. manual), ADVPN tuning, and the IPsec Phase 1/2 mismatch playbook for when an overlay tunnel won't come up. Back to the Knowledge Base, or browse more Networking guides.