What the FortiManager SD-WAN Overlay Wizard Actually Configures

Throughout, watch for these four labels — they're the whole point of the article: Underlay Overlay Routing SD-WAN. The wizard mixes all four on the same screens; naming them is how you stay oriented.

SD-WAN fabric = underlay (WAN) + overlay (IPsec) + routing (BGP) + SD-WAN (zones + SLA + rules)

01One wizard, four layers — the map

Before the walkthrough, here's the whole wizard on one page: every stage, what it emits, and the layer that object really lives in. Keep this as your key.

Notice that only one of those rows is actually SD-WAN. The wizard's name is the headline feature, but two-thirds of what it writes is overlay and routing — the substrate SD-WAN steers over. That mirrors the split from the overlay vs underlay guide.

02Topology & role — the blueprint

The first screens ask for topology (single hub, dual hub, or multi-region hub-and-spoke) and then which managed devices are hubs and which are spokes. This isn't a config layer of its own — it's the blueprint that determines how many tunnels, which BGP role, and which SD-WAN zones each device ends up with.

• Hub → becomes the IPsec responder, the BGP route reflector, and the SLA target.
• Spoke → becomes the IPsec initiator, a BGP client, and the device that runs SD-WAN rules.
• Region → groups spokes to a hub pair and scopes ADVPN shortcuts.

Pick this wrong and every downstream layer is wrong, so it's worth slowing down here.

03WAN interfaces & loopbacks — the underlay Underlay

Next the wizard maps each device's WAN/underlay interfaces — typically through normalized interfaces and metadata variables so one template fits many devices with different port layouts. It also creates a loopback per device to anchor BGP and the SLA probes.

This is pure underlay: raw reachability to the internet/MPLS. Nothing here is SD-WAN yet — but it's the foundation, because the overlay tunnels are built over these interfaces and the routing peers via the loopbacks.

Underlay = WAN interfaces (per-device mapped) + loopbacks (stable peering IPs)

04The overlay — IPsec tunnels Overlay

Now the wizard builds the overlay: an IPsec tunnel from each spoke WAN to each hub, generated as phase 1 / phase 2 interface definitions with tunnel IP addressing, IKE proposals, and — the important part — ADVPN so spokes can form dynamic shortcuts to each other. Every tunnel gets a network-id and the whole set becomes the private topology.

# ── OVERLAY ── one IPsec tunnel to the hub, per WAN
config vpn ipsec phase1-interface
    edit "H1-ISP1"
        set interface "port1"                 # underlay port (metadata-mapped)
        set peertype any
        set net-device disable
        set proposal aes256-sha256
        set add-route disable                  # let BGP own routing, not IPsec
        set auto-discovery-receiver enable     # ADVPN spoke shortcut
        set network-id 1
        set psksecret ******
    next
end

Two things to note: add-route disable means the overlay deliberately does not install routes — that job is handed to BGP in the next stage. And ADVPN is an overlay feature, not an SD-WAN one: it changes how the logical topology forms, independent of any path decision.

05The routing — BGP over the overlay Routing

With tunnels up, something has to advertise which prefixes live where. The wizard generates a full BGP design: an AS number, neighbor groups peering on the loopbacks, a route reflector on the hub, and network statements advertising each site's LAN. It also enables recursive routing and additional-path so ADVPN shortcuts are usable.

# ── ROUTING ── iBGP to the hub loopback, ADVPN-aware
config router bgp
    set as 65000
    config neighbor-group
        edit "H1"
            set remote-as 65000
            set additional-path receive        # accept ADVPN shortcut paths
            set next-hop-self enable
        next
    end
    config network
        edit 1
            set prefix 10.20.0.0 255.255.255.0 # advertise this branch LAN
        next
    end
end

This is the layer people mistake for SD-WAN, because it decides reachability. But BGP only answers "is there a path, and via which member?" — it populates the candidate routes. Choosing among equal candidates by quality is the next, separate layer.

Routing = BGP AS + loopback peering + route reflector (hub) + LAN advertisement

06SD-WAN — zones, members, SLA & rules SD-WAN

Only now does the wizard configure actual SD-WAN. It creates the zones (an overlay zone holding the tunnel interfaces, plus an underlay/internet zone), enrolls each tunnel and WAN as a member, defines performance SLA health-checks probing the hub loopback, and optionally adds rules that steer applications. It also links BGP to SD-WAN so route priority follows SLA state.

# ── SD-WAN ── overlay zone, member, SLA probe to the hub
config system sdwan
    set status enable
    config zone
        edit "overlay"
        next
    end
    config members
        edit 1
            set interface "H1-ISP1"            # the overlay tunnel from stage 04
            set zone "overlay"
        next
    end
    config health-check
        edit "HUB-SLA"
            set server "10.255.0.1"            # hub loopback from stage 03
            set members 1
        next
    end
end

Everything the SD-WAN layer references was built by the earlier stages: the member is the overlay tunnel, the SLA server is an underlay loopback, and the routes that make the member usable came from BGP. That dependency chain is exactly why the wizard bundles them — and exactly why naming the layers matters when one link breaks.

SD-WAN (this layer) = zones + members + SLA health-checks + rules

07What FortiManager actually ships to the devices

The wizard doesn't push loose commands — it produces reusable provisioning artifacts, which is why the same design scales to hundreds of spokes:

Assign, then Install Wizard renders each template against a device's metadata and pushes the result. Because the layers are separate templates, you can later edit the routing without touching the overlay, or tune SD-WAN rules without re-keying a single tunnel.

08The takeaway

"SD-WAN wizard" is a friendly name for a full branch-fabric generator. If you remember one thing: most of what it writes isn't SD-WAN. It builds the underlay mapping, an IPsec overlay, and a BGP routing design first — and only then the thin, powerful SD-WAN layer that steers across them. Keep the four labels in your head and every screen of the wizard, and every later troubleshooting session, reads cleanly:

SD-WAN fabric = underlay (WAN) + overlay (IPsec) + routing (BGP) + SD-WAN (zones + SLA + rules)

Want the layer beneath this? See how a packet is actually steered in How SD-WAN Traffic Steering Works — Step by Step, and the zone/overlay design in SD-WAN Overlay vs Underlay.