FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
cvincent_FTNT
Article Id 190100

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 :

rmetzger_FD30543_rpf_example_1.JPG

 
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: