Course menu

Module 4: Routing and SD-WANLesson 4.4 (4 of 4 in this module)18 of 18 in the FortiGate Administrator course

Lab: two ISPs with SD-WAN

Add a second Internet link, build an SD-WAN zone with a health check, steer traffic by SLA, and fix four routing faults.

Intermediate · 25 min read

What you will learn

After this lesson, you can migrate a single-ISP FortiGate to SD-WAN with two links, a health check and a rule, and diagnose the faults that typically appear during the migration.

  • Static routes
  • SD-WAN
  • Health checks
  • Troubleshooting

An SD-WAN migration moves a FortiGate's WAN interfaces from being used directly by routes and policies to being members of an SD-WAN zone. References to the interfaces are removed, the members are added with their gateways, one static route and the policies point at the zone, and health checks and rules decide which member each session uses.

In simple terms: You stop telling the FortiGate 'use port1' everywhere, and instead say 'use the Internet zone', then let SD-WAN pick the link.

The situation

FGT1 is in its state after the NAT lab: port1 to ISP1 with a default route, policies 3 (LAN-to-Internet, with Staff-Pool), 5 (LAN-to-Payments) and 6 (Internet-to-WEB1) referencing port1. A second link arrives on port4: 192.0.2.2/30, gateway 192.0.2.1. Video calls should use whichever link meets a quality SLA, preferring port1; other traffic may use both.

port2port1port4PC1LAN · 10.0.1.10FGT1SD-WAN zoneISP1fibre · gw 203.0.113.1ISP2broadband · gw 192.0.2.1
  1. 1. Normally: Video calls use port1 while it meets the SLA.
  2. 2. Degraded: When port1 misses the SLA, new calls use port4.

Task 1: address port4

Show the configuration
config system interface edit port4 set ip 192.0.2.2 255.255.255.252 set role wan set allowaccess ping next end

Task 2: remove direct references to port1

Show the configuration
config system sdwan set status enable config zone edit "virtual-wan-link" next end end config firewall policy edit 3 set dstintf "virtual-wan-link" set ippool disable next edit 5 set dstintf "virtual-wan-link" next edit 6 set srcintf "virtual-wan-link" next end config router static delete 1 end

The zone can exist before it has members, so the policies can move to it first. Staff-Pool's addresses belong to ISP1, so policy 3 goes back to the interface address: a pool address leaving through ISP2 would be dropped by ISP2. (Policy 5 still needs its pool; the faults section returns to this.)

Task 3: members, route and health check

Show the configuration
config system sdwan config members edit 1 set interface "port1" set zone "virtual-wan-link" set gateway 203.0.113.1 next edit 2 set interface "port4" set zone "virtual-wan-link" set gateway 192.0.2.1 next end config health-check edit "Internet-SLA" set server "8.8.8.8" "1.1.1.1" set protocol ping set members 1 2 config sla edit 1 set latency-threshold 150 set jitter-threshold 30 set packetloss-threshold 2 next end next end end config router static edit 1 set sdwan-zone "virtual-wan-link" next end

Task 4: the video rule

Show the configuration
config system sdwan config service edit 1 set name "Video-calls" set mode sla set internet-service enable set internet-service-name "Zoom-Zoom.Meeting" config sla edit "Internet-SLA" set id 1 next end set priority-members 1 2 next end end

Task 5: verify

  • get router info routing-table all: two default routes, one via each member.
  • diagnose sys sdwan health-check: both members alive, with their latency, jitter and loss.
  • diagnose sys sdwan service: the rule's members in their current order.
  • Start a call from PC1 and check its session's outgoing interface in diagnose sys session list.

Find the fault

Fault 1

Adding port4 as a member fails: FortiOS reports that the interface is in use.

Show diagnosis

Something still references port4: a firewall policy, a static route, a policy route from an earlier test or a DHCP server. Find it with the Ref. column on Network › Interfaces, or:

diagnose sys cmdb refcnt show system.interface.name port4

Lists every table entry that references port4. Remove or repoint those, then add the member.

Fault 2

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # get router info routing-table all
Routing table for VRF=0
C       10.0.1.0/24 is directly connected, port2
C       10.0.2.0/24 is directly connected, port3
C       192.0.2.0/30 is directly connected, port4
C       203.0.113.0/30 is directly connected, port1

Members and the health check are up, but nothing reaches the Internet.

Show diagnosis

No default route: the old route 1 was deleted and the route to the SD-WAN zone was never added. Fix: config router static, edit 1, set sdwan-zone "virtual-wan-link".

Fault 3

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # diagnose sys sdwan health-check
Health Check(Internet-SLA):
Seq(1 port1): state(dead), packet-loss(100.000%) sla_map=0x0
Seq(2 port4): state(dead), packet-loss(100.000%) sla_map=0x0

Both members are marked dead and Internet access has stopped, yet both ISPs confirm their links are fine, and execute ping from FGT1 to their gateways works.

Show diagnosis

The links work; the probes don't. A dead member's routes are withdrawn, so a broken health check takes the links out of service. The health check's server was set to a host that drops ICMP (for example a company website). Fix: use servers that answer the chosen protocol, or change the protocol (HTTP, DNS, TCP echo) to one the server answers.

Fault 4

Payments work most of the time, but some sessions fail. The failing ones look like this:

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # diagnose sys session list (one session, trimmed)
orgin->sink: org pre->post, reply pre->post dev=5->7/7->5 gwy=192.0.2.1/10.0.1.10
hook=post dir=org act=snat 10.0.1.10:53002->192.0.2.50:443(203.0.113.17:53002)
misc=0 policy_id=5 ...
Show diagnosis

The session leaves through port4 (gateway 192.0.2.1) with a source from Payments-Pool, which belongs to ISP1. ISP2 drops traffic from addresses that aren't its own (and replies would return via ISP1 anyway). Fix: make payment traffic always use port1 with an SD-WAN rule (strategy Manual, member port1) placed above the others, since the provider whitelists the pool address anyway.

Check yourself

Predict · scenario 1

After moving to SD-WAN, which outgoing interface should LAN-to-Internet policies use?

Predict · scenario 2

Why can an IP pool from ISP1's range break sessions that SD-WAN sends through ISP2?