SD-WAN with FortiGate: connecting several sites without expensive leased lines

For a long time, connecting a head office to its branches meant leasing dedicated lines, expensive and slow to install. SD-WAN changes the equation: several ordinary internet links, fibre or 4G/5G, become a reliable private network thanks to an intelligent appliance at each site. For a managing director or IT manager at an SMB, in Morocco, Africa or Europe, the question is no longer “do we need a leased line?” but “how do we make ordinary links work together without users noticing the difference?”. As a Fortinet partner since 2021, here is how FortiGate SD-WAN works, how we design it, and the mistakes we fix most often.

The principle

A FortiGate firewall at each site builds encrypted IPsec tunnels to the other sites over every available internet link. It continuously measures latency, jitter and packet loss on each path, and steers each type of traffic onto the best link at that moment. If a link goes down or degrades, failover is automatic and invisible to users.

SD-WAN is built into FortiOS: no extra box and no dedicated licence for the feature itself. The same appliance handles the firewall, threat inspection, VPN and smart routing, which keeps a multi-site network much simpler to run.

The building blocks of FortiGate SD-WAN

Four concepts come up in every design, and they are worth knowing before you read a quote.

Building block	Role	What needs deciding
SD-WAN members and zones	Group a site’s internet links and tunnels	Which links, which carrier, which backup
Quality probes (Performance SLA)	Measure latency, jitter and loss towards a target	Targets tested and acceptable thresholds per use
SD-WAN rules	Pick the link for each application or destination	Strategy: best quality, meet a threshold, load balancing or manual choice
Tunnel topology	Connect the sites together	Hub-and-spoke around head office, or direct branch-to-branch tunnels with ADVPN

Rules rely on the FortiGate’s application recognition: telephony, the ERP, Microsoft 365 and Windows updates can be handled differently even when they all use the same port. That is the difference with a simple dual-WAN router, which fails over wholesale without telling uses apart.

What it changes day to day

• Voice stays clear: IP telephony is prioritised and pinned to the most stable link.
• The ERP responds: critical applications go before Windows updates and video.
• A carrier outage goes unnoticed: the second link takes over automatically.
• Remote work is secure: staff connect over VPN, with the same security rules as in the office.
• Administration is centralised: one consistent policy across every site, instead of improvised configurations branch by branch.

Choosing links: diversity before bandwidth

Two links from the same carrier, arriving through the same duct, often fail together. SD-WAN only delivers real continuity if the paths are genuinely different: two carriers, or one fibre plus 4G/5G access. For a small branch, one fibre and a 4G/5G router are often enough; for a head office hosting the ERP and the phone system, two fibres from different carriers plus a radio backup are the safer choice. How to choose a business fibre link is covered in our guide to business fibre in Morocco.

The FortiGate must then be able to inspect the sum of the active links, not just the fastest one. It is an often-forgotten sizing point, which we explain in which FortiGate model to choose.

A trap to know about

SD-WAN spreads traffic across links. Some flows hate that: SIP, SBC tunnels, long-lived connections to a file server or database. Without an explicit rule, a session can switch links mid-stream and drop. We pin those flows to a single link at design time, with a defined backup, and we check failover behaviour before going live. It is a detail that separates a successful deployment from a painful one. Other causes of dropped calls and echo are reviewed in the 10 mistakes that ruin call quality.

Our method, step by step

1. Map the flows: who talks to what, between which sites, with which critical applications (ERP, telephony, file sharing, email).
2. Inventory each site’s links: carrier, technology, real throughput, fixed IP address or not, physical entry point.
3. Choose the topology: hub-and-spoke around head office in most cases, direct tunnels between branches when they exchange a lot with each other.
4. Define probes and thresholds per use: voice tolerates far less jitter than a file sync.
5. Write per-application rules, pinning sensitive flows and putting updates and streaming last.
6. Test failover site by site, actually unplugging each link, with calls in progress.
7. Monitor: link quality, failovers and saturation feed into our console, with an alert before users start complaining.

The mistakes we fix most often

1. Two links from the same carrier presented as “redundant” when they share the same infrastructure.
2. A single quality probe to a single target, which declares a link dead when only the target has stopped responding.
3. Identical thresholds for every use, so voice stays on a degraded link.
4. Telephony and SBC not pinned: calls drop at every failover.
5. A 4G/5G backup never tested, whose data plan or SIM card has expired on the day it is needed.
6. A head-office appliance sized like a branch, saturated by all the tunnels.
7. Different firmware versions from site to site, which complicate troubleshooting and leave vulnerabilities open.
8. No documentation: nobody remembers why a given rule sends a given flow down a given link.

Checklist before starting an SD-WAN project

• List of sites, users per site and remote workers.
• Critical applications identified, with their location (head office, cloud, branch).
• Two genuinely different paths for each important site: separate carriers or technologies.
• FortiGate model for each site sized on throughput with inspection and number of tunnels.
• Topology chosen: hub-and-spoke, or direct branch-to-branch tunnels.
• Quality thresholds defined per use, voice first.
• Sensitive flows pinned: SIP, SBC, long-lived connections.
• Failover test plan, carried out under real conditions.
• Monitoring and alerts in place from day one.

Who is it for?

Any company with at least two sites, or one site plus remote workers, that depends on telephony or a central ERP. Multi-clinic healthcare groups, service companies with branches, manufacturers with a remote warehouse, retail networks: this is our most common case. A single site with two internet links benefits too: even without tunnels between sites, SD-WAN balances the load and fails over automatically between links.

How we deploy it

We start with a free audit of your sites, links and flows, then propose an architecture and a transparent hardware and licensing quote. Deployment happens site by site, alongside the existing setup, so business never stops. The network then joins our 24/7 monitoring, with critical incidents handled in under 15 minutes. Several projects of this kind are described, without client names, in our case studies.

All of this is part of our network infrastructure and WiFi service. To look at connecting your sites, contact us: we reply within 24 business hours.