Course menu

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

Routing on a FortiGate

The routing table, distance and priority, ECMP, blackhole routes, link monitors and the reverse path check that drops spoofed traffic.

Intermediate · 12 min read

What you will learn

After this lesson, you can predict which route a FortiGate uses, configure static routes with distance and priority, remove a dead route automatically with a link monitor, and recognise a reverse path check drop.

  • Route selection
  • Distance and priority
  • Link monitor
  • RPF check

FortiGate routing chooses the outgoing interface and next hop for each new session from the routing table. The most specific matching prefix wins; among routes to the same prefix the lowest administrative distance is installed, and among installed routes with equal distance the lowest priority is used. Equal distance and priority give ECMP load sharing.

In simple terms: The FortiGate picks the most exact route for the destination. If several are equally exact, it prefers the most trusted source, then the lowest priority number.

A real-life situation

FGT1 gets a second Internet link on port4 from another ISP (192.0.2.2/30, gateway 192.0.2.1) as a backup. Simply adding a second default route makes traffic split or flap unexpectedly; giving it the wrong distance means the backup never takes over. And when the primary ISP's router stays up but its upstream fails, the route never disappears. Getting backup links right means understanding how FortiOS picks a route.

How a route is chosen

  1. Longest prefix: 10.0.3.0/24 beats 10.0.0.0/16 beats 0.0.0.0/0.
  2. Distance between routes to the same prefix: the lowest is installed in the routing table; others stay in the routing database as standby.
  3. Priority between installed static routes with the same distance: the lowest is used for new sessions.
  4. ECMP when prefix, distance and priority are all equal: sessions are shared (by source IP, by default).

Primary and backup default routes

config router static edit 1 set gateway 203.0.113.1 set device port1 set distance 10 next edit 2 set gateway 192.0.2.1 set device port4 set distance 20 next end

Route 2 has a higher distance, so it stays out of the routing table while route 1 is valid. A policy from port2 to port4 (with NAT) is still needed for traffic to use the backup.

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # get router info routing-table database
S    *> 0.0.0.0/0 [10/0] via 203.0.113.1, port1
S       0.0.0.0/0 [20/0] via 192.0.2.1, port4
C    *> 10.0.1.0/24 is directly connected, port2
...
The database lists every route; *> marks the ones in the routing table. The routing table itself (get router info routing-table all) shows only the distance-10 route. (Example output, trimmed.)

Alternatively, give both routes the same distance and different priorities: both are then in the routing table, the lower priority carries new sessions, and replies to traffic arriving on the backup link can still use it. This matters for inbound services on both ISPs.

Detecting a dead link: link health monitor

A static route stays as long as its interface is up. If the ISP's router is up but its network is down, port1 stays up and traffic disappears. A link health monitor probes beyond the gateway and removes the route when probes fail:

config system link-monitor edit ISP1-check set srcintf "port1" set server "8.8.8.8" "1.1.1.1" set gateway-ip 203.0.113.1 set protocol ping set interval 500 set failtime 5 set recoverytime 5 set update-static-route enable next end

Probes every 500 ms; after 5 failures the routes through port1's gateway are removed and the distance-20 backup is installed; after 5 successes they return. (SD-WAN, two lessons on, does this and more.)

Blackhole routes

config router static edit 10 set dst 10.0.3.0 255.255.255.0 set blackhole enable set distance 254 next end

A typical use with VPNs: while the tunnel to the branch (10.0.3.0/24) is up, its route (distance 10 or similar) wins. If the tunnel drops, traffic for the branch hits this blackhole instead of following the default route to the Internet unencrypted.

The reverse path check

For the first packet of a session, the FortiGate checks that the source address is reachable through the interface the packet arrived on. If not, the packet is dropped as possibly spoofed. Debug flow shows it plainly:

Example output · based on Fortinet documentation; exact format varies by model and FortiOS version
FGT1 # (debug flow, trimmed)
msg="vd-root:0 received a packet(proto=1, 10.9.9.5:1->10.0.2.10:2048) from port2. type=8, code=0, id=1, seq=0."
msg="reverse path check fail, drop"
A device on the LAN uses 10.9.9.5, a subnet FGT1 has no route for via port2. Add a route for 10.9.9.0/24 via port2 (if that network really is behind the LAN), or fix the device's address.

By default the check is loose: any route back through that interface, including a default route, passes. Strict mode (set strict-src-check enable under config system settings) requires the best route to point back that way.

Why it works this way

Longest prefix and distance are the same rules every router uses. Priority exists because a firewall often needs a backup route to be present in the routing table (for replies, health checks and the RPF check) without carrying new traffic. The RPF check uses the routing table to spot packets whose source couldn't legitimately come from that side.

Common mistakes

  • Adding a backup default route with the same distance and priority, creating ECMP by accident.
  • Relying on interface state alone to detect a failed ISP.
  • Forgetting the firewall policy for the backup interface: the route switches but traffic is denied.
  • Adding a new internal subnet behind a LAN router without a route on the FortiGate, then seeing RPF drops.

Key takeaways

✅ Key takeaways
  • Longest prefix, then lowest distance, then lowest priority; equal everything is ECMP.
  • The routing database holds standby routes; the routing table holds active ones.
  • Link health monitors remove routes when the path beyond the gateway fails.
  • Blackhole routes stop VPN traffic leaking; RPF check failures mean an unexpected source.

Check yourself

Predict · scenario 1

Two default routes: port1 distance 10, port4 distance 20. Both links are up. Which is in the routing table?

Predict · scenario 2

Two default routes have the same distance; port1 has priority 1, port4 priority 5. What happens?

Predict · scenario 3

Debug flow shows "reverse path check fail, drop" for traffic from 172.16.5.10 arriving on port2. What does it mean?

FAQ

Why do I see two default routes but only one is used?
If both have the same distance, both are installed in the routing table, and the one with the lower priority carries new sessions; the other is a ready backup. If their distances differ, only the lower-distance route is in the routing table; the other waits in the routing database.
Does FortiGate support dynamic routing?
Yes: OSPF, BGP, RIP and IS-IS, configured under config router. The same distance and longest-prefix rules decide between dynamic and static routes.