A branch can show two healthy WAN circuits while business traffic is already failing. Packet loss, DNS latency, asymmetric routing, and poorly ordered policies can make a basic dual-WAN setup look operational in the dashboard but unreliable to users. This Fortinet SD-WAN configuration guide focuses on the design decisions and validation steps that prevent that outcome in enterprise branch deployments.

FortiGate SD-WAN configuration is not simply a matter of adding two interfaces and selecting load balancing. The appliance must know how to measure path quality, which applications receive priority, when a session should move to another link, and how the return path remains valid. The right result depends on circuit types, addressing, security inspection requirements, application mix, and the FortiOS release running on the firewall.

Start With the WAN and Traffic Design

Before entering commands or using the GUI, document each WAN circuit’s handoff, IP addressing, gateway, bandwidth, and expected service level. Identify whether the provider uses static addressing, DHCP, PPPoE, LTE, or an upstream router. This determines interface configuration and may affect MTU, VLAN tagging, link monitoring, and NAT behavior.

Also classify traffic by operational value. Real-time voice, video conferencing, ERP, payment services, remote desktop, cloud applications, general web browsing, and backups should not necessarily use the same steering rule. A small branch with broadband and LTE may send most traffic over broadband and reserve LTE for failure conditions. A larger site with DIA, MPLS, and internet VPN may require application-aware selection with circuit-specific preferences.

Confirm the hardware and software baseline

Verify the FortiGate model has sufficient throughput for the enabled security profiles, IPsec tunnels, expected session count, and WAN bandwidth. SD-WAN decisions are made on the firewall, but IPS, SSL inspection, antivirus, and logging can change real-world capacity substantially. An undersized appliance often appears to have an SD-WAN problem when the actual bottleneck is CPU utilization or inspection throughput.

Confirm the FortiOS version and use its matching administration and CLI references. Syntax, default behavior, health-check options, and SD-WAN rule features can vary between releases. Back up the current configuration before changes, and schedule a maintenance window when modifying a production firewall’s default route, interface membership, or security policies.

Fortinet SD-WAN Configuration Guide: Core Build Sequence

The cleanest approach is to build in layers: physical interfaces, SD-WAN members, performance SLAs, steering rules, routing, then security policies. Testing each layer limits the scope of troubleshooting.

Configure WAN interfaces first

Configure each ISP-facing interface with the correct mode and gateway information. Assign descriptive aliases such as `ISP1-DIA`, `ISP2-Broadband`, or `LTE-Backup`; this matters when operations teams must diagnose an outage months later. Confirm that each interface can reach its next-hop gateway before placing it into SD-WAN.

In a typical CLI workflow, the physical interfaces are defined under `config system interface`. The exact addressing method varies, but the intent is consistent: establish connectivity on each transport before applying SD-WAN logic. Do not use overlapping address ranges on separate WAN interfaces unless the design explicitly supports them.

If an ISP supplies a managed router, clarify whether FortiGate receives a public IP address, a private transit network, or NATed internet access. That detail affects inbound publishing, IPsec peer configuration, dynamic DNS, and troubleshooting expectations.

Add members and define the SD-WAN zone

Add each active transport as an SD-WAN member and set the correct gateway. Configure realistic estimated bandwidth values where your FortiOS release supports them. These values are not a substitute for SLA measurement, but they assist reporting and some load-distribution decisions.

Use a logical SD-WAN zone in firewall policies rather than writing separate outbound policies for every WAN interface. This reduces policy duplication and makes future circuit replacement easier. The zone-based model is especially useful for standardized branch deployments managed by a central network team.

A simplified configuration pattern may resemble the following. Interface names, gateways, and member IDs must match the site design.

“` config system sdwan set status enable config members edit 1 set interface “wan1” set gateway 203.0.113.1 next edit 2 set interface “wan2” set gateway 198.51.100.1 next end end “`

Avoid copying gateway addresses from sample configurations into a live device. Validate them against the provider handoff sheet and test reachability from the correct interface.

Build performance SLAs around real destinations

A performance SLA, also called a health check, determines whether a link is acceptable for a given traffic class. Configure multiple reliable targets rather than relying on a single public IP. A provider gateway proves only the first hop; it does not prove that the circuit can reach the internet or a SaaS application reliably.

For general internet reachability, use stable public DNS resolvers or other approved targets. For critical services, consider testing the application destination or a controlled monitoring endpoint. Set latency, jitter, and packet-loss thresholds according to the traffic requirement. Voice may require tighter jitter and loss limits than web browsing, while backup traffic can tolerate a degraded path.

Aggressive thresholds can cause path flapping when a circuit has minor variation. Loose thresholds can keep sensitive traffic on a poor link for too long. Start with provider performance data and adjust after observing branch behavior during business hours.

Create steering rules in business order

SD-WAN rules are evaluated in order, so place the most specific and business-critical rules first. For example, voice and video can prefer the circuit that meets the real-time SLA, with a second circuit permitted only if it also passes the same SLA. Cloud productivity traffic can use the lowest-latency qualified path. Bulk updates and guest traffic can use a lower-cost broadband link or be rate-limited.

Do not create a separate rule for every application without a clear operational requirement. Excessive rule granularity increases troubleshooting time and can create conflicts when signatures, addresses, or ports overlap. For many branches, a focused set of rules for real-time traffic, business applications, tunnel traffic, general internet access, and low-priority traffic is easier to operate.

Session behavior requires attention. Existing TCP sessions may remain on their selected path until they expire, while new sessions follow the updated rule decision. For stateful applications, frequent link switching can be more disruptive than temporarily accepting a less preferred path. Use quality thresholds and hold-down behavior that reflect application tolerance.

Route through SD-WAN and align security policies

Create a default route that points to the SD-WAN virtual interface or zone, according to the FortiOS version and configuration model. Remove or adjust competing static default routes that bypass SD-WAN selection. More-specific routes for private networks, IPsec overlays, management paths, or data center prefixes should remain deliberate and documented.

Firewall policies must permit the desired source networks to the SD-WAN zone. Enable NAT for ordinary internet-bound traffic when the WAN circuits use public addressing and no upstream NAT device is handling translation. Do not enable NAT automatically for private WAN, MPLS, or site-to-site overlay traffic; it can break routing and obscure source networks needed by remote sites.

For branches using IPsec tunnels to a hub or cloud security edge, decide whether the underlay circuit selection is handled by SD-WAN and whether overlay traffic has its own SLA rule. This is a common design point: an internet breakout policy may select links based on public targets, while overlay paths need health checks that reflect tunnel or application reachability.

Validate Failure Behavior Before Handover

A green interface status is not sufficient acceptance testing. Test the configuration using controlled failures and record the observed result. Disconnect one WAN circuit, block its upstream gateway where practical, and simulate degraded quality if your lab or provider tools allow it. Confirm that new sessions choose the intended path, critical applications remain usable, and routes recover predictably when the circuit returns.

Use FortiGate monitoring views and CLI diagnostics to check member state, SLA measurements, selected rules, routing tables, and active sessions. Review logs for denied traffic after policy changes. If failover appears inconsistent, investigate policy order, route distance, health-check targets, NAT, DNS resolution, and asymmetric return traffic before changing thresholds blindly.

Maintain the configuration as circuits change

SD-WAN designs age quickly when carrier services, SaaS endpoints, branch bandwidth, or application priorities change. Review SLA history after an outage and determine whether the failure was detected soon enough and whether the fallback path had the capacity to carry priority traffic. LTE may be an effective continuity link, for example, but it may not be appropriate for unrestricted backups or software distribution.

For replacement firewalls, spare units, interface modules, transceivers, and power components, match the required FortiGate model and port specifications to the deployed design before procurement. Gear Net Technologies supports infrastructure buyers that need precise network hardware sourcing for rollout, maintenance, and replacement requirements.

A well-configured SD-WAN deployment gives operations teams a measurable policy for path selection rather than a collection of manual failover assumptions. Keep the configuration documented, test it under realistic fault conditions, and let application requirements – not interface labels – determine how each branch uses its available connectivity.

imrank21

I am an enthusiastic tech blogger with 15 years of experience in the technology field. I am passionate about sharing valuable insights and helping people who are interested in technology gain useful and practical information. I am originally from Mumbai, India.