1. Executive Summary

Title: FortiGate Reverse Path Forwarding (RPF): Configuration, When to Use It, and How to Troubleshoot It

Objective: Explain exactly how FortiOS performs its Reverse Path Forwarding (RPF) anti-spoofing check, configure loose mode, strict mode, and per-interface exemptions correctly, and give you a repeatable workflow for proving (or ruling out) RPF as the reason a new session never shows up.

Target audience: Network and security engineers who run FortiGates in NAT mode with more than one path in or out: dual WAN, SD-WAN, IPsec hubs, and internal L3 cores. You should be comfortable in the FortiOS CLI.

RPF is one of those checks that works quietly for years and then eats a production service the day someone adds a backup ISP or a second core router. When it drops a packet there is no session, no policy hit, and usually no forward traffic log. If you know where to look, it takes two commands to confirm. If you don’t, it takes an afternoon of staring at firewall policies that are not the problem.

2. How RPF Works on a FortiGate

When the first packet of a new session arrives, FortiOS asks one question about the source address before it ever looks at firewall policy: could I route back to this source out of the interface it just arrived on? If the answer is no, the packet is treated as spoofed and dropped. The debug flow message for this is reverse path check fail, drop.

A few details matter more than the headline:

• It runs on session creation only. RPF is evaluated for the first packet of a session (the SYN for TCP). Packets that match an existing session are not re-checked against RPF.
• It runs before policy lookup. A packet that fails RPF never reaches the policy table, which is why you will not see an implicit deny (policy 0) hit or a forward traffic log for it.
• It uses the active routing table (RIB/FIB), not the routing database. A floating static route that is configured but not installed because it has a higher distance does not count. Neither do policy routes or SD-WAN service rules, because those are steering decisions, not routes.
• It uses the original source IP. The check happens before any source NAT is applied on egress, and the VIP/DNAT destination has no bearing on it.
• It is evaluated per VRF. With VRFs configured, the lookup happens in the VRF of the ingress interface.
• It is not multicast RPF. Multicast routing (PIM) has its own RPF logic tied to the path toward the source or RP. This post covers the unicast anti-spoofing check only.

Loose vs. strict mode

FortiOS offers two evaluation modes, set per VDOM, plus a per-interface switch that turns the check off entirely for traffic arriving on that interface.

A concrete way to see the difference: a packet arrives on wan1 with a spoofed source of 10.0.1.25, which is actually your LAN. In loose mode the default route out of wan1 matches 10.0.1.25, so the check passes and the packet moves on to policy (where hopefully nothing allows it). In strict mode the best route to 10.0.1.25 is the connected route on port1, not wan1, so the packet is dropped at RPF.

Now flip it: a LAN host on port1 sends a packet sourced from 172.16.99.10, a range that exists nowhere behind port1. The only route that matches is the default route out of wan1. Loose mode drops it (no route through port1), and so does strict mode. This is the anti-spoofing that the default configuration already gives you, and it is the reason most internal spoofing never makes it past a FortiGate.

3. Prerequisites and Architecture

Assumed knowledge

• FortiOS CLI navigation, config / edit / set / end workflow, and VDOM context if you run multi-VDOM.
• Static route attributes: distance vs. priority, and how FortiOS decides which routes are installed.
• Basic use of diagnose debug flow and diagnose sniffer packet.

Lab requirements

• One FortiGate in NAT mode running FortiOS 7.2, 7.4, or 7.6. The syntax covered here has been stable across 6.x and 7.x.
• Two WAN uplinks (or two simulated upstream routers) and one internal segment with a downstream L3 router.
• A Linux host on the LAN with hping3 installed for the spoof tests.
• Lab addressing follows the InfoSecMonkey convention: 198.18.0.0/15 stands in for public and transit space, 10.0.0.0/16 for internal LANs.

Lab components

4. When to Use Each Mode

The honest answer for most deployments is: leave loose mode on, make your routing table tell the truth, and only reach for strict mode or per-interface exemptions when you have a specific reason. Here is how that plays out in real designs.

5. Step-by-Step Implementation Workflow

Step 1: Baseline the current RPF state

Goal: Know which mode the VDOM uses and whether any interface already has RPF disabled before you change anything.

Action: Check the VDOM setting and search every interface for a non-default src-check.

show full-configuration system settings | grep strict-src-check
show system interface | grep -f src-check

Expected output on a default build shows set strict-src-check disable. The second command only prints interfaces where src-check was changed (non-default values appear in show), so no output means every interface is still enforcing RPF.

GUI Verification: None. Both settings are CLI-only. Record the output in your change ticket.

Step 2: Make the routing table tell the truth

Goal: Ensure every legitimate source has an active route through the interface it arrives on. This is what keeps loose mode quiet in multi-path designs.

Action: Configure both default routes with the same distance and different priorities, so both are installed in the RIB while wan1 stays preferred for outbound traffic. Add routes for anything that lives behind a downstream router.

config router static
    edit 1
        set gateway 198.18.1.1
        set device "wan1"
        set distance 10
        set priority 1
    next
    edit 2
        set gateway 198.18.2.1
        set device "wan2"
        set distance 10
        set priority 10
    next
    edit 3
        set dst 10.0.50.0 255.255.255.0
        set gateway 10.0.1.254
        set device "port1"
    next
end

Because both defaults are active, a session that arrives on wan2 (for example to the VIP on wan2) passes loose RPF, and FortiOS returns the reply out wan2 since a valid route through that interface exists. If wan2 had distance 20 instead, its route would sit in the routing database, not the RIB, and every inbound session on wan2 would fail RPF.

For IPsec, make sure the remote subnets have a route through the tunnel interface, either statically, via add-route enable on dial-up phase1 definitions, or through BGP/OSPF over the tunnel.

config router static
    edit 10
        set dst 10.0.60.0 255.255.255.0
        set device "to-site-b"
    next
end

GUI Verification: Dashboard > Network > Static & Dynamic Routing (the Routing Monitor). Both 0.0.0.0/0 entries and the 10.0.50.0/24 and 10.0.60.0/24 routes should be listed as active.

Step 3 (optional): Enable strict mode for the VDOM

Goal: Require the ingress interface to be the best route back to the source.

Action: Enable strict source checking. This applies to every interface in the VDOM, so do it in a maintenance window and run Section 6 immediately afterward.

config system settings
    set strict-src-check enable
end

To revert:

config system settings
    set strict-src-check disable
end

GUI Verification: None. Confirm with show full-configuration system settings | grep strict-src-check.

Step 4 (optional): Exempt a single interface

Goal: Stop RPF drops on one interface where asymmetric arrival is intentional and cannot be fixed with routing, while every other interface keeps anti-spoofing.

Action: Disable src-check on that interface only.

config system interface
    edit "port5"
        set src-check disable
    next
end

Document why in the interface description or comments. An exempt interface is an easy thing to forget during the next audit, and it is exactly where a spoofed source will get through.

config system interface
    edit "port5"
        set description "src-check disabled: partner transit, CHG-2026-0412"
    next
end

GUI Verification: None for src-check itself. The description is visible under Network > Interfaces.

Step 5: Prove the check with a controlled spoof

Goal: Confirm RPF drops what it should drop, and see the exact debug signature so you recognize it in production.

Action: Start a debug flow filtered on the spoofed source, then send a few SYNs from the LAN test host using a source address that is not routed behind port1.

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter addr 172.16.99.10
diagnose debug flow show function-name enable
diagnose debug console timestamp enable
diagnose debug flow trace start 20
diagnose debug enable

From the Linux test host (10.0.1.50):

sudo hping3 -S -p 443 -c 3 -a 172.16.99.10 198.18.200.10

Stop the debug when you are done:

diagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clear

GUI Verification: None. RPF drops happen before policy, so Log & Report > Forward Traffic will not show these packets. The CLI output in Section 6 is the evidence.

6. Verification and Validation

Expected result: spoofed source dropped

The debug flow for each spoofed SYN should look like this (IDs, line numbers, and function names vary by build):

id=65308 trace_id=1 func=print_pkt_detail line=5895
  msg="vd-root:0 received a packet(proto=6,
  172.16.99.10:2471->198.18.200.10:443) tun_id=0.0.0.0
  from port1. flag [S], seq 1784210593, ack 0, win 512"
id=65308 trace_id=1 func=init_ip_session_common line=6076
  msg="allocate a new session-0003b1a4, tun_id=0.0.0.0"
id=65308 trace_id=1 func=vf_ip_route_input_common line=2605
  msg="reverse path check fail, drop"

Three things in that output confirm RPF: the packet was received, no policy ID appears anywhere, and the last message is reverse path check fail, drop. Output is wrapped here for readability; on the console each message is a single line.

Expected result: legitimate traffic passes

Repeat the test with a real LAN source (drop the -a flag) and a filter on 10.0.1.50. You should see the route lookup, a policy match, and allowed by Policy-N instead of the RPF drop:

func=vf_ip_route_input_common msg="find a route: flag=04000000
  gw-198.18.1.1 via wan1"
func=fw_forward_handler msg="Allowed by Policy-1: SNAT"

Validate the routing that RPF will use

For any source you care about, ask FortiOS directly which route it would use to reach that source:

get router info routing-table details 10.0.50.10

Expected output when the core router route from Step 2 is in place:

Routing table for VRF=0
Routing entry for 10.0.50.0/24
  Known via "static", distance 10, metric 0, best
  * vrf 0 10.0.1.254, via port1

If the answer is the default route via wan1, any packet sourced from 10.0.50.10 arriving on port1 will fail RPF in both loose and strict mode. That single command settles most RPF tickets.

To confirm both default routes are active (not just configured) for the dual-WAN case:

get router info routing-table all | grep 0.0.0.0/0
get router info routing-table database | grep 0.0.0.0/0

Both wan1 and wan2 defaults should appear in routing-table all. If wan2 appears only in the database output, it is configured but not installed, and inbound sessions on wan2 will fail RPF.

7. Troubleshooting and Gotchas

The workflow below is the same one to use in production whenever a new session silently fails. It takes less than five minutes and either proves or eliminates RPF.

1. Confirm the packet actually arrives. Run diagnose sniffer packet any 'host <src> and host <dst>' 4 0 l. You want to see the packet ingress on the expected interface and nothing egress.
2. Run a filtered debug flow on the source address (Step 5 commands). If the last message is reverse path check fail, drop, it is RPF. If you see a policy ID, it is not RPF.
3. Ask the routing table with get router info routing-table details <src>. The interface in the answer versus the ingress interface from the sniffer tells you exactly why the check failed.
4. Fix the route, not the check. Add or correct the route, rerun the test, and only consider src-check disable if the asymmetry is intentional.

Gotcha 1: Inbound services on the backup WAN stop working

Symptom: A VIP or remote-access service on wan2 works during a failover test but not when wan1 is up. The sniffer shows SYNs arriving on wan2 and nothing leaving.

Diagnosis: The wan2 default route has a higher distance than wan1, so it is not in the active routing table. Loose RPF finds no active route to the internet source through wan2.

get router info routing-table database | grep 0.0.0.0/0
diagnose debug flow filter addr <client-public-ip>

Resolution: Give both default routes the same distance and use priority to prefer wan1, as in Step 2. With SD-WAN, place both links in the SD-WAN zone so each member contributes an active route. If strict mode is enabled, this design will still fail on wan2; go back to loose mode.

Gotcha 2: A subnet behind an internal router is dropped

Symptom: Users on 10.0.50.0/24 (behind the core router) cannot reach anything through the FortiGate, while hosts on 10.0.1.0/24 work fine. No forward traffic logs exist for the branch subnet.

Diagnosis: There is no route to 10.0.50.0/24 via port1, so the only match is the default route out of wan1.

get router info routing-table details 10.0.50.10

Resolution: Add the static route (or a summary such as 10.0.0.0/16 via 10.0.1.254) or learn it via OSPF/BGP from the core. Do not disable src-check on the LAN interface to work around a missing route; that removes anti-spoofing for your entire user segment.

Gotcha 3: VPN traffic dropped after a tunnel or BGP flap

Symptom: A tunnel is up and phase 2 selectors are correct, but traffic from the remote site is dropped for a period after the tunnel comes up, or permanently on a dial-up tunnel.

Diagnosis: The route to the remote subnet is missing. Common causes are BGP over IPsec still converging, add-route disable on a dial-up phase1, or a static route pointing at the wrong tunnel interface.

diagnose vpn tunnel list name to-site-b
get router info bgp summary
get router info routing-table details 10.0.60.10

Resolution: Make sure a route through the tunnel interface exists for every remote source. On dial-up tunnels either keep add-route enable or advertise the routes dynamically. If you keep a blackhole route for the remote subnet (distance 254) to stop leaks when the tunnel is down, that is fine; it only becomes active when the tunnel route disappears.

Gotcha 4: Policy routes and SD-WAN rules do not satisfy RPF

Symptom: A policy route or SD-WAN rule steers return traffic for a partner network out port3, but traffic from that partner arriving on port3 is dropped.

Diagnosis: RPF checks the routing table only. Policy routes (diagnose firewall proute list) are steering entries, not routes.

Resolution: Add a real static route for the partner prefixes through port3 (a higher priority is fine for loose mode; a higher distance is not if a lower-distance route to the same prefix exists, because it will not be installed), or disable src-check on port3 and document it.

Gotcha 5: Strict mode enabled, random multi-path failures

Symptom: After enabling strict-src-check, some flows fail intermittently, often around failovers, ECMP changes, or BGP best-path changes.

Diagnosis: In strict mode, the ingress interface must be the current best route. Any design where traffic can legitimately arrive on a non-preferred path will fail.

Resolution: Revert to loose mode (set strict-src-check disable) for that VDOM. If you need strict anti-spoofing only for a subset of segments, move those segments into their own VDOM and enable strict mode there.

Reading the drop message correctly

Not every silent drop is RPF. Match the last debug flow message to its cause before you change anything:

8. Quick Reference

9. Wrapping Up

RPF on a FortiGate is simple once you internalize three facts: it only checks the source, it only uses active routes, and it runs before policy. Keep loose mode as your default, make every legitimate source routable through the interface it arrives on, use strict mode where there is exactly one correct path, and treat src-check disable as a documented exception. When a session silently disappears, a sniffer, a filtered debug flow, and one routing-table lookup will tell you whether RPF is the culprit in minutes.