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:
- 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.
- 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"
Related articles: