Technical Tip: Details about FortiOS RPF (Reverse Path Forwarding), also called Anti-Spoofing

[cvincent_FTNT]

Description

This article explains FortiOS RPF, or Anti-Spoofing.

Scope

FortiGate or VDOM running in NAT mode.    

Solution

FortiGate implements a mechanism called RPF (Reverse Path Forwarding), or Anti-Spoofing, which prevents an IP packet from being forwarded if its Source IP does not meet either of the following conditions:

• Belong to a locally attached subnet (local interface).
  
• Exist in the routing of the FortiGate from another source (static route, RIP, OSPF, BGP).

If none of these conditions are 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 (for example, when using a DMZ with Mail or WEB services)..
2. RPF (or anti-spoofing) can be disabled if asymmetric routing has been enabled. This is 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 commands (this is disabled by default - a per-VDOM command):

config system settings
     set asymroute enable
end

The following diagram illustrates the behavior of RPF :

In the first case, it is assumed that FGT2 does not have a route for 172.16.1.0/24 on the dmz interface.

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 pings 192.168.11.1 for example, the packets from PC1 are dropped by FGT2.

The packets are seen arriving on FGT2 but never routed out:

diagnose 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.

diagnose 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:

diagnose debug flow

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

In the second case, a route is put back to PC1 (172.16.1.0/24) in the routing table of 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:

diagnose debug flow
diagnose 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"

Additionally, if the Reverse path check fails in Virtual IP configuration, the following logs are seen:

date=2024-08-02 time=18:35:31 id=7398566193721773246 itime="2024-08-02 18:35:29" euid=3 epid=101 dsteuid=3 dstepid=101 logflag=2 logver=702081639 type="traffic" subtype="forward" level="warning" action="deny" policyid=0 sessionid=1379965275 srcip=99.8.2.2 dstip=213.186.16.20 tranip=172.16.19.1 srcport=60149 dstport=8443 tranport=8443 trandisp="dnat" duration=0 proto=6 sentbyte=0 rcvdbyte=0 sentpkt=0 rcvdpkt=0 logid=0000000007 service="TCP-8443" app="TCP-8443" appcat="unscanned" srcintfrole="lan" dstintfrole="undefined" policytype="policy" eventtime=1722612925653261693 srccountry="Ireland" dstcountry="Jordan" srcintf="OUT" dstintf="unknown-0" msg="reverse path check fail, drop" tz="+0300" devid="FGxxxxxx" vd="root" dtime="2024-08-02 18:35:31" itime_t=1722612929 devname="Firewall"

In this case, 'dstintfrole="undefined"' is shown and no MAC address is visible for 'tranip=172.16.19.1'. This means it may be because rap entry is not available on the firewall for 172.16.19.1.

To verify this, run the following command:

get sys arp

Related articles:

Technical Tip: Setting priority on static default routes to create a primary (preferred) and a secon...

Troubleshooting Tip: First steps to troubleshoot connectivity problems to or through a FortiGate wit...

Technical Tip: Routing behavior depending on distance and priority for static routes, and Policy Bas...

Troubleshooting Tip: debug flow messages 'iprope_in_check() check failed, drop' - 'Denied by forward...