Technical Note: Details about FortiOS RPF (Reverse Path Forwarding), also called Anti-Spoofing
Products
FortiGate
FortiGate v4.0
FortiGate v5.0
FortiGate v5.2
FortiGate v5.4
Description
The FortiGate implements a mechanism called RPF (Reverse Path Forwarding), or Anti Spoofing, which prevents an IP packet to be forwarded if its Source IP does not either:
If those conditions are not met, the FortiGate will silently drop the packet.

Notes :
 
1 -  Because of RPF, a FortiGate connected to the Internet with one or more interfaces needs an active route (usually a default route) on all of its interfaces where sessions can be initiated (example: when having a DMZ with Mail or WEB services).

See related article "Configuring Dual Internet Links (Design Considerations)" and "Load sharing between two WAN interfaces" for more information.

 
2 -  RPF (or anti spoofing) can be disabled if asymmetric routing has been enabled. This is however not recommended except as a test to determine whether asymmetric routing is causing a problem in the network.


To enable asymmetric routing use the following CLI command (disabled by default - a per-VDOM command):
config system settings
     set asymroute enable
end
Scope
FortiGate or VDOM running in NAT mode.    
Solution
The following diagram is used to illustrate the behavior of RPF :

 
In the first case, we assume that FGT2 does not have a route for 172.16.1.0/24 on the dmz interface .
fgt2 # get router info routing-table all
S*      0.0.0.0/0 [10/0] via 192.168.11.254, wan1
C       10.1.1.0/24 is directly connected, dmz
C       192.168.11.0/24 is directly connected, wan1
When PC1 is pinging for example 192.168.11.1, the packets from PC1 are dropped by FGT2.
 
The packets are seen arriving on FGT2 but never routed out:
fgt2 # diag sniffer packet any "icmp" 192.168.11.1

3.415367 dmz in 172.16.1.1 -> 192.168.11.1: icmp: echo request
8.914795 dmz in 172.16.1.1 -> 192.168.11.1: icmp: echo request 


When using the debug flow command prior to 4.0MR1 , the FortiGate will not process any further than after a new session was allocated. This is a typical symptom of anti spoofing being triggered.
fgt2 # diag debug flow
id=20085 trace_id=3 msg="vd-root received a packet(proto=1, 172.16.1.1:1280->192.168.11.1:8) from dmz."
id=20085 trace_id=3 msg="allocate a new session-00000d69"
id=20085 trace_id=4 msg="vd-root received a packet(proto=1, 172.16.1.1:1280->192.168.11.1:8) from dmz."
id=20085 trace_id=4 msg="allocate a new session-00000d70" 
When using the debug flow command since 4.0MR1, the message about rpf is displayed :

       fgt2 # diag debug flow
 

 id=20085 trace_id=5 msg="reverse path check fail, drop"





In the second case, we put a route back to PC1 (172.16.1.0/24) in the routing table of FGT2:
fgt2 # get router info routing-table all
S*      0.0.0.0/0 [10/0] via 192.168.11.254, wan1
C       10.1.1.0/24 is directly connected, dmz
S       172.16.1.0/24 [10/0] via 10.1.1.10, dmz
C       192.168.11.0/24 is directly connected, wan1
The sniffer trace combined with a debug flow now shows more activity:
fgt2 # diag debug flow
fgt2 # diag sniffer packet  any "icmp" 192.168.11.1

3.309385 dmz in 172.16.1.1 -> 192.168.11.1: icmp: echo request
3.309696 wan1 out 192.168.11.20 -> 192.168.11.1: icmp: echo request

id=20085 trace_id=29 msg="vd-root received a packet(proto=1, 172.16.1.1:1280->192.168.11.1:8) from dmz."
id=20085 trace_id=29 msg="allocate a new session-00000f32"
id=20085 trace_id=29 msg="find a route: gw-192.168.11.254 via wan1"
id=20085 trace_id=29 msg="find SNAT: IP-192.168.11.20, port-52040"
id=20085 trace_id=29 msg="Allowed by Policy-2: SNAT"
id=20085 trace_id=29 msg="SNAT 172.16.1.1->192.168.11.20:52040"

3.333468 wan1 in 192.168.11.1 -> 192.168.11.20: icmp: echo reply
3.333664 dmz out 192.168.11.1 -> 172.16.1.1: icmp: echo reply

id=20085 trace_id=30 msg="vd-root received a packet(proto=1, 192.168.11.1:52040->192.168.11.20:0) from wan1."
id=20085 trace_id=30 msg="Find an existing session, id-00000f32, reply direction"
id=20085 trace_id=30 msg="DNAT 192.168.11.20:0->172.16.1.1:1280"
id=20085 trace_id=30 msg="find a route: gw-10.1.1.10 via dmz"

Related Articles
Troubleshooting Tip : First steps to troubleshoot connectivity problems to or through a FortiGate with sniffer, debug flow, session list, routing table
Technical Note : Setting priority on static default routes to create a primary (preferred) and a secondary path
Troubleshooting Tip : debug flow messages "iprope_in_check() check failed, drop" - "Denied by forward policy check" - "reverse path check fail, drop"
Technical Note: Routing behavior depending on distance and priority for static routes, and Policy Based Routes
Last Modified Date: 03-14-2019 Document ID: FD30543