End internet outages: dual WAN with FortiGate SD-WAN

Most businesses discover how dependent they are on a single internet line at the worst possible moment. A second line is the obvious answer — but a second line that requires someone to change a setting during the outage is barely better than no second line at all.

Why a simple backup line disappoints

The traditional approach configures a static failover: if the primary link goes down, route everything over the secondary. It works, with two significant gaps.

• It only detects hard failures. If the line is technically up but losing 30% of packets, the router sees a working interface and keeps using it. From the user's side this is worse than an outage — calls break up, sessions hang, and nothing has officially failed.
• Existing sessions drop. When the switch happens, everything in flight resets. Video calls end, file transfers restart, remote desktop sessions disconnect.

What SD-WAN changes

FortiGate's SD-WAN treats the two lines as a single logical interface with active health measurement behind it.

• Health checks run continuously. The appliance probes a target across each link and measures latency, jitter and packet loss — not just whether the interface is up.
• Quality thresholds trigger action. You define what unacceptable means: above 150 ms latency, above 2% loss. When a link crosses the threshold, traffic moves.
• Both lines can carry traffic. Rather than one line idling, you can distribute load and use the capacity you are already paying for.

Steering by application

This is where it becomes genuinely useful rather than just resilient.

Different traffic has different requirements. Voice and video care about jitter and loss but use little bandwidth. Backup replication cares about throughput and does not care about latency at all. Ordinary browsing sits in between.

So: put voice and video on the fibre with the tight quality threshold; send backup traffic and large downloads over the cheaper secondary; let general browsing use whichever link is healthier at that moment. A single policy set expresses all of it.

What it does not solve

Two honest limitations.

Your public IP changes on failover. If you host services that must be reachable from outside — a VPN endpoint, a mail server, a published application — clients pointing at the primary IP will not follow. Solving this properly needs either provider-independent addressing with BGP, or DNS with a short TTL and automated updating, or a cloud-hosted entry point.

Two lines from the same provider on the same physical path are one line. We have seen "redundant" pairs where both circuits ran through the same street cabinet. When a contractor cut the duct, both went together. Ask your provider about the physical route, and prefer genuinely different media — fibre plus fixed wireless, or fibre plus a different carrier.

Practical configuration notes

• Choose health check targets carefully. Probing a single public DNS server means its maintenance window looks like your link failing. Use at least two targets, and where possible something on your own infrastructure.
• Set thresholds from measurement. Default values are a starting point. Measure your links for a week first and set thresholds that reflect normal for you.
• Test the failover deliberately. Physically unplug the primary during a quiet window and watch what happens. An untested failover design is a hypothesis.
• Watch what fails over. Some applications tolerate an IP change mid-session and some do not. Knowing which is which before the outage is the point of testing.