Reverse Path Forwarding on Fortigate Firewalls

What is spoofing?  Back in the days of security being on routers via ACLs, we would regularly fool the routers into passing packets by crafting a packet with a SourceIP that lived on the inside of the router. This would fool the router by saying to itself  “Oh this is a packet sourced from the inside, since that packet is coming from the inside and heading to the inside, I guess it is OK to pass it”  When we realized this, we started creating access-lists and assigning them to the outside interface (or whatever the inbound connection was coming from that you wanted to enable anti-spoofing:

In the example above, we would have created an access-list that would block anything coming from 10.1.1.0/24 coming in from 1.1.1.1/24 .  Since a packet would never be coming from the Internet with a 10.1.1.0/24 address.

Fortigates have a method of blocking spoofing attacks known as Reverse Path Forwarding (RFP).  RPF protects against IP Spoofing attacks as well as routing loops. RFP will check the source IP address for a valid route.  The Fortigate will check the first packet only when the session is created.

If you the check fails, the following error will be thrown-up

reverse path check fail, drop

There are two RPF check modes; The default, feasible path (formerly known as loose) and strict.

In Feasible Mode, the packet is accepted as long as there is one active route to the source IP through the incoming interface.

In strict mode, FortiGate checks that the best route to the source IP address is through the incoming interface. The route not only has to be active (as in the case of feasible path mode), but it also has to be the best.

Particularly with Strict Mode, there is a phenomenon where if you have a particular scenario, you can break things.  Here is the scenario:

What we are seeing in the picture above is a workstation 10.2.1.10 with a default gateway of 10.2.1.254 on link (1).  As we can see, the Fortigate has a static route to the 10.2.1.0/24 network via 10.1.1.254 on the local switch interface (3) but also has an OSPF route learned from port 3 via 10.3.1.254.  As you know, OSPF has an administrative cost of 110 while the static route has a admin cost of 10.

In this scenario, the workstation will send a packet out to the Internet via its default gateway on (1) since it is its default gateway.  The router 10.2.1.254 will forward the packet to the Fortigate via (5) to 10.3.1.1.  The Fortigate will enter the session coming from its port 3.  When the packet comes back,  the Fortigate will look at the packet and since it has a better route via its static route (cost of 10), the packet will be out of state and considered to have failed the RPF.

The point here is, beware of your networking environment before you enable strict mode for RFP.

If you are controlling your upstream router, you CAN combine the RPF feature on the Fortigate while still having the upstream router config I described in the beginning of this post.