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). See the related articles 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 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.1.1 for example, the packets from PC1 are dropped by FGT2.

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

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.

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:

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

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

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

If the issue is related to ARP, refer to this ARP troubleshooting guide.

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