FortiGate SD-WAN + ZTNA: The Complete Walk-Through

The Swiggy delivery network — a routing problem you already understand

You order biryani on Swiggy at 8 PM. The order goes to a dispatcher. The dispatcher looks at three things in real time: which delivery partner is closest, which one has the highest rating, and which route avoids the Outer Ring Road jam right now. The biryani always arrives — but the path changes based on traffic. That dispatcher is FortiGate SD-WAN. The delivery partners are your WAN underlays (MPLS, broadband, 4G). The "real time" data is the Performance SLA. The biryani is your application traffic.

Now imagine Swiggy stops giving the delivery partner the whole apartment building's master key and instead generates a one-time door code valid for just that order, valid only for the 3rd floor, valid only between 8-9 PM. That is ZTNA. A traditional SSL-VPN hands the user the master key (LAN access). ZTNA hands them a session-scoped, application-scoped, posture-verified one-time code.

Why this matters — interview-grade and production-grade

If you are interviewing for a Fortinet admin role in 2026, the panel will ask two questions back-to-back: "explain SD-WAN application steering" and "why is your CISO replacing SSL-VPN with ZTNA?" The first answer separates the GUI-clickers from the engineers. The second separates the engineers from the architects. This blog gets you both.

FortiGate SD-WAN — the core concept

SD-WAN on FortiGate is built from three things layered on top of each other:

1. SD-WAN Zone — a logical grouping of member interfaces (e.g. virtual-wan-zone). Once an interface is added to a zone, it disappears from the regular interface list and is referenced as zone-name.
2. Performance SLA — the health probe (HTTP / DNS / Ping / TCP-echo / TWAMP). Targets a public server (e.g. 8.8.8.8) or a private one. Measures latency, jitter, packet-loss. Triggers a "member failed" event when thresholds break.
3. SD-WAN Rule — the steering policy. "If source X talks to destination Y (or app Z), prefer the member with best latency / best quality / lowest cost." Applied in order, first match wins.

config system sdwan
    set status enable
    config zone
        edit "virtual-wan-zone"
        next
    end
    config members
        edit 1
            set interface "port1"
            set zone "virtual-wan-zone"
            set comment "MPLS underlay"
        next
        edit 2
            set interface "port2"
            set zone "virtual-wan-zone"
            set comment "Broadband underlay"
        next
    end
    config health-check
        edit "M365-probe"
            set server "outlook.office365.com"
            set protocol http
            set http-get "/"
            set http-match "200"
            set interval 1000
            set failtime 5
            set members 1 2
            config sla
                edit 1
                    set latency-threshold 60
                    set jitter-threshold 20
                    set packetloss-threshold 1
                next
            end
        next
    end
    config service
        edit 1
            set name "M365-steer"
            set mode sla
            set internet-service enable
            set internet-service-app-ctrl 41540 41541
            config sla
                edit "M365-probe"
                    set id 1
                next
            end
            set priority-members 1 2
        next
    end
end

FGT # diagnose sys sdwan health-check status M365-probe
Health Check (M365-probe):
Seq(1 port1):  state=alive,  packet-loss=0.000%  latency=18.123  jitter=2.111  sla_map=0x1
Seq(2 port2):  state=alive,  packet-loss=0.200%  latency=42.001  jitter=4.890  sla_map=0x1

BGP-over-IPsec overlay — when branches need to talk to branches

SD-WAN gets one branch to the internet/SaaS cleanly. Real enterprises also need branch-to-branch (Pune-to-Lucknow office for an internal CRM). The pattern Fortinet pushes is ADVPN with iBGP on top.

config router bgp
    set as 65001
    set router-id 10.50.255.1
    config neighbor-group
        edit "ADVPN-spokes"
            set advertisement-interval 1
            set link-down-failover enable
            set next-hop-self enable
            set additional-path send
            set remote-as 65001
            set route-reflector-client enable
        next
    end
    config neighbor-range
        edit 1
            set prefix 10.50.255.0/24
            set neighbor-group "ADVPN-spokes"
        next
    end
    config network
        edit 1
            set prefix 10.50.0.0 255.255.0.0
        next
    end
end

The NSE7 SD-WAN trap: candidates pick eBGP for the overlay because "different AS = more isolation." Wrong. iBGP preserves the next-hop attribute — without it, ADVPN spokes can't resolve each other's tunnel endpoints and shortcut tunnels never come up. Memorise: iBGP over IPsec for ADVPN, always.

ZTNA on FortiGate — the architecture

FortiGate ZTNA is built from three components:

1. FortiClient EMS — runs in your DC or cloud. Profiles user devices, runs Zero-Trust tagging rules (AV installed? On-domain? Specific registry key? OS patched?), issues short-lived client certs.
2. ZTNA tags — synced from EMS to FortiGate in real-time. Every endpoint shows up with a set of tags like EMS_All_Registered_Clients, tag_av_installed, tag_corp_domain_joined.
3. Access Proxy VIP — on the FortiGate. Listens on HTTPS, terminates the user's TLS connection, checks the client cert + ZTNA tags + ZTNA policy, then proxies to the real internal app. The internal app is never directly exposed.

config firewall access-proxy
    edit "ap_internal_jira"
        set vip "vip_ztna_proxy"          # listens on 203.0.113.10:443
        set client-cert enable
        config api-gateway
            edit 1
                set url-map "jira.corp.local"
                set service https
                config realservers
                    edit 1
                        set address "jira-prod"    # internal address object 10.60.10.20
                        set port 443
                    next
                end
            next
        end
    next
end
config firewall policy
    edit 100
        set name "ZTNA_jira_corp_users"
        set srcintf "any"
        set dstintf "any"
        set ztna-status enable
        set ztna-ems-tag "tag_corp_domain_joined" "tag_av_installed"
        set srcaddr "all"
        set dstaddr "vip_ztna_proxy"
        set action accept
        set schedule "always"
        set service "HTTPS"
    next
end

The 4 SD-WAN failures you'll diagnose in your first month

Sources used in this lesson

1. FortiOS 7.6.6 — Basic ZTNA configuration
2. FortiOS 7.6.6 — ZTNA configuration examples
3. FortiOS 7.6 — Configuring the SD-WAN interface
4. FortiOS 7.6 — Basic SD-WAN configuration (MSSP architecture)
5. Fortinet — ZTNA vs VPN: the better cybersecurity solution
6. FortiClient EMS 7.4 — Security Posture Tags
7. NSE7 SD-WAN 7.2 — exam blueprint and topic detail