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:
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:
- belong to a locally attached subnet (local interface), or
- be in the routing of the FortiGate from another source (static route, RIP, OSPF, BGP)
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.
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):
To enable asymmetric routing use the following CLI command (disabled by default - a per-VDOM command):
config system settings
set asymroute enable
end
ScopeFortiGate or VDOM running in NAT mode.
SolutionThe 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, wan1When 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 flowWhen using the debug flow command since 4.0MR1, the message about rpf is displayed :
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"
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, wan1The 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 requestid=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 replyid=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"
Internal Notes
Another article will talk about strict-rpf check.
Reviewed/Updated by Cale Vincent (June 2016).Related Articles
