Software-Defined WAN (SD-WAN) abstracts the WAN transport layer — allowing organizations to use multiple internet links (broadband, 4G/5G, MPLS) simultaneously, with intelligent traffic steering based on real-time link quality measurements. The result is better application performance, higher availability, and dramatically lower WAN costs compared to dedicated MPLS circuits.
This guide covers SD-WAN design principles, FortiGate SD-WAN configuration, migration strategy from MPLS, and ongoing operations — giving you everything needed to plan and execute a successful SD-WAN deployment.
1 What is SD-WAN & When to Use It
SD-WAN uses a centralized control plane to make intelligent, policy-driven decisions about how traffic flows across multiple WAN connections — replacing static routing with dynamic, application-aware path selection.
WAN Technology Comparison
| Technology |
Cost |
Performance |
Flexibility |
Best For |
| MPLS |
Very High |
Predictable SLA |
Low |
Legacy critical apps, latency-sensitive voice |
| SD-WAN (ILL + Broadband) |
Low–Medium |
High (multi-path) |
Very High |
Most enterprise branch deployments |
| Broadband Only |
Very Low |
Variable |
Medium |
Small offices, non-critical sites |
| 4G/5G Backup |
Medium |
Variable |
High |
Failover, temporary sites, remote locations |
| SASE (Cloud SD-WAN) |
Medium |
High |
Very High |
Cloud-first, remote work-heavy organizations |
✅ Pro Tip: SD-WAN saves 40–60% vs MPLS for most organizations — but not all workloads are suitable. Latency-sensitive applications like VoIP still need QoS guarantees that not all SD-WAN providers deliver equally. Audit your application portfolio before committing to a vendor — test with your actual critical applications, not just synthetic benchmarks.
SD-WAN Use Cases
- Branch Office Connectivity: Replace expensive MPLS with dual internet links + intelligent failover
- Cloud Application Performance: Direct internet breakout for SaaS (Microsoft 365, Salesforce) instead of backhauling to HQ
- WAN Redundancy: Automatic failover between ISPs with sub-second detection — no manual intervention
- Bandwidth Aggregation: Combine multiple links for higher effective throughput
- Centralized Management: Configure and monitor all branch WAN connections from a single dashboard
2 Underlay Network Design
The underlay is the physical transport — the actual internet or private circuits that SD-WAN overlay tunnels run across. Poor underlay design negates the benefits of even the best SD-WAN solution.
Recommended Underlay Architecture
- Primary Link: ILL (Internet Lease Line) — dedicated, symmetric, SLA-backed. Best for critical applications and primary VPN tunnels
- Secondary Link: Broadband (fiber/cable) — high bandwidth, lower cost, best-effort. Carries bulk traffic and serves as failover
- Tertiary / Out-of-Band: 4G/5G LTE — activates only on dual-link failure. Keeps management access alive for remote troubleshooting
ISP Selection Criteria
- Latency to HQ / cloud regions: Measure baseline RTT — target <10ms intra-city, <30ms intra-country for voice workloads
- Packet loss baseline: Acceptable WAN should show <0.1% packet loss under normal load
- Jitter: For VoIP, target <30ms jitter — test at multiple times of day including peak hours
- SLA and support: ILL should include a documented SLA with financial penalties for breaches
- BGP availability: For multi-homed sites, confirm the ISP supports BGP peering for proper failover
⚠️ Warning: Never deploy SD-WAN with two links from the same ISP — even if they appear as separate circuits. A single ISP infrastructure failure (fiber cut, POP outage, BGP route leak) will take both links down simultaneously. True redundancy requires physically diverse ISPs using different last-mile infrastructure.
3 SD-WAN Policy & Traffic Steering
Traffic steering rules define which applications use which WAN links under which conditions — this is where SD-WAN delivers its real value over static routing.
Application-Aware Routing
- VoIP / Video Conferencing: Steer to the link with best jitter and packet loss metrics — latency matters less than consistency
- ERP / Database: Steer to ILL primary — reliability over cost
- Microsoft 365 / SaaS: Direct internet breakout — bypass HQ backhaul entirely for better performance
- General Browsing: Load balance across all available links — maximize utilization
- Backup / Large File Transfer: Use lowest-cost link during off-peak hours — avoid saturating the ILL
SLA Probe Design
SD-WAN makes path selection decisions based on SLA probes — continuous measurements of link quality. Design your probes carefully:
⚠️ Warning: Never rely on a single SLA probe metric. Measure latency, jitter, AND packet loss simultaneously — a link with low latency but 5% packet loss is worse for VoIP than a slightly higher-latency clean link. Configure compound SLA thresholds that consider all three metrics together.
- Probe destination: Use a stable, always-available target — 8.8.8.8 or your HQ firewall, not a public website that may go down
- Probe interval: 500ms for latency-sensitive applications, 1s for general traffic — faster detection of degradation
- Probe protocol: ICMP for basic latency; HTTP probes for more realistic application-level measurement
- Failure detection: Trigger failover after 3 consecutive probe failures — balances speed vs false positives
4 FortiGate SD-WAN Configuration
FortiGate has native SD-WAN built into FortiOS — no additional licensing required beyond the base FortiGate license for core SD-WAN functionality.
SD-WAN Zone and Member Setup
# Create SD-WAN zone with members via CLI
config system sdwan
set status enable
config zone
edit "wan-zone"
next
end
config members
edit 1
set interface "wan1"
set zone "wan-zone"
set gateway 203.0.113.1
set cost 0
set priority 1
set comment "ILL-Primary"
next
edit 2
set interface "wan2"
set zone "wan-zone"
set gateway 198.51.100.1
set cost 5
set priority 2
set comment "Broadband-Secondary"
next
edit 3
set interface "lte1"
set zone "wan-zone"
set cost 10
set priority 3
set comment "4G-Tertiary-Backup"
next
end
end
Health Check (SLA Probe) Configuration
config system sdwan
config health-check
edit "HQ-Health-Check"
set server "8.8.8.8"
set protocol ping
set interval 500
set failtime 3
set recoverytime 5
config sla
edit 1
set latency-threshold 150
set jitter-threshold 30
set packetloss-threshold 1
next
end
set members 1 2 3
next
end
end
SD-WAN Rule — VoIP Priority
config system sdwan
config service
edit 1
set name "VoIP-Priority-ILL"
set mode sla
set dst "all"
set src "10.10.0.0/24"
set protocol 17
set dst-port 5060 5061 16384-32767
config sla
edit "HQ-Health-Check"
set id 1
next
end
set priority-members 1 2
next
edit 2
set name "SaaS-Direct-Breakout"
set mode priority
set internet-service enable
set internet-service-app-ctrl 49160 41720
set priority-members 2 1
next
end
end
✅ Pro Tip: Use FortiGate's Internet Service Database (ISDB) for SaaS traffic steering. It maintains up-to-date IP and FQDN lists for Microsoft 365, Google Workspace, Salesforce, and hundreds of other SaaS applications — eliminating the need to manually maintain destination address objects for cloud services that constantly change their IP ranges.
5 Zero-Touch Provisioning (ZTP)
Zero-Touch Provisioning allows new branch FortiGate devices to be deployed by non-technical staff — the device boots, connects to FortiManager or FortiCloud, downloads its configuration, and is production-ready without any on-site engineer.
ZTP Prerequisites
- FortiManager or FortiCloud: Central management platform where device templates are pre-staged
- Device registration: Serial numbers registered to the FortiCloud account before shipping
- Template configuration: Full device config template prepared in FortiManager, including SD-WAN policies
- DHCP at branch: Branch must have internet connectivity via DHCP on the WAN port for initial phone-home
ZTP Workflow
- Pre-stage device configuration template in FortiManager for the target branch
- Register device serial number to FortiCloud / FortiManager
- Ship the FortiGate to the branch — include only: "Plug WAN port into ISP modem, plug LAN port into switch, power on"
- Device boots, connects to FortiGuard via DHCP, authenticates with FortiCloud using serial number
- FortiManager pushes full configuration — SD-WAN zones, policies, VPN tunnels, firewall rules
- Branch is operational within 10–15 minutes of power-on, no engineer on-site required
✅ Pro Tip: For large branch rollouts (10+ sites), ZTP can save 2–3 engineer-days per site in travel and on-site configuration time. At scale, the ROI of FortiManager licensing pays for itself within the first 5–10 branch deployments purely in reduced travel and labor costs.
6 Application Performance Monitoring
After deployment, continuous monitoring of application performance across your SD-WAN fabric is essential — both for proactive issue detection and for demonstrating business value.
Key Metrics to Monitor
- Per-link latency, jitter, packet loss: Real-time and historical trends per WAN member
- Bandwidth utilization per link: Peak, average, and 95th percentile — used for capacity planning
- Path selection events: How often and why traffic was moved between links — indicates link instability
- Application SLA compliance: Percentage of time each application met its SLA threshold
- Failover events: When, which link failed, duration of degradation, recovery time
FortiAnalyzer SD-WAN Dashboard
- Connect FortiAnalyzer to all FortiGate devices for centralized log collection
- Use built-in SD-WAN dashboards: FortiView → SD-WAN for real-time path visualization
- Build custom reports for weekly WAN performance summary — send to management automatically
- Configure threshold alerts: alert when any link exceeds 80% utilization or SLA breach occurs
⚠️ Warning: Do not wait for users to report problems — by the time a user calls the help desk about slow application performance, the issue has typically been ongoing for 30–60 minutes. Proactive monitoring with automated alerting catches degradation before it impacts users.
7 Security Integration
SD-WAN and security are inseparable — direct internet breakout at branches means each branch firewall is now a full internet edge, not just a WAN router. Security must be part of the SD-WAN design, not an afterthought.
Branch Security Requirements
- NGFW at every branch: Full deep packet inspection, IPS, and application control — not just routing
- DNS Security: FortiGuard DNS filtering or Cisco Umbrella to block malicious domains at every branch
- SSL Inspection: Required for any branch with direct internet breakout — you cannot inspect what you cannot see
- Central Security Logging: All branch firewall logs to FortiAnalyzer or SIEM — no blind spots
SASE Consideration
For organizations with many branches or a predominantly remote workforce, SASE (Secure Access Service Edge) combines SD-WAN with cloud-delivered security (SWG, CASB, ZTNA) — eliminating the need for full security stacks at each branch:
- Fortinet SASE: FortiSASE — integrates with existing FortiGate infrastructure
- Cisco Meraki + Umbrella: Simple management with cloud security
- Zscaler: Pure cloud security proxy — SD-WAN tunnels to Zscaler PoPs
- Palo Alto Prisma SASE: Enterprise-grade, broad feature set
✅ Pro Tip: For branches with fewer than 50 users, SASE is often more cost-effective than deploying full on-prem NGFW security stacks at each location. Calculate the per-branch cost of FortiGate + FortiAnalyzer + FortiManager vs a per-user SASE subscription — SASE typically wins at lower user counts.
8 Migration Strategy
Migrating from MPLS to SD-WAN is a significant infrastructure change that must be executed carefully to avoid business disruption. A phased approach is essential — never cut over all sites simultaneously.
Phased Migration Plan
- Phase 0 — Assessment (Week 1–2): Inventory all WAN circuits, costs, contract end dates, application dependencies, and current performance baselines
- Phase 1 — Pilot Site (Week 3–6): Deploy SD-WAN at a low-risk site. Run MPLS and SD-WAN in parallel (hybrid mode). Validate performance and failover behavior for 2 weeks before trusting SD-WAN as primary
- Phase 2 — Expand (Week 7–16): Deploy to remaining sites in batches of 3–5. Keep MPLS running in parallel during the transition period at each site
- Phase 3 — MPLS Decommission (Week 17–24): After 30 days of stable SD-WAN operation at each site, cancel MPLS circuits. Stagger cancellations to align with contract end dates to avoid early termination fees
- Phase 4 — Optimization (Ongoing): Tune SLA thresholds, traffic steering rules, and security policies based on real operational data
⚠️ Warning: Never cancel MPLS circuits until you have at least 30 days of proven SD-WAN operation at each site — including at least one real failover event that you observed and validated. Theoretical failover and tested failover are very different things. Cutting MPLS before validation leaves you with no fallback if SD-WAN has hidden issues.
Rollback Planning
- Keep MPLS contracts active and circuits in place throughout Phase 1 and Phase 2
- Document the exact routing changes needed to revert to MPLS-primary at any site within 15 minutes
- Test rollback procedure at the pilot site before proceeding to Phase 2
- Maintain MPLS as backup (non-preferred route) for 30 days post-migration at each site before cancellation
Ready to Deploy SD-WAN?
EnterWeb IT Firm designs and deploys SD-WAN solutions across India — from pilot deployments to full multi-site rollouts on FortiGate, Cisco Meraki, and other platforms. We handle design, deployment, migration, and ongoing management.