What is a Reverse Path Forwarding check and how does it work on FortiGates?

A quick intro to RPF check concepts

What is a Reverse Path Forwarding check and how does it work on FortiGates?
Photo by Braydon Anderson / Unsplash
đź’ˇ
This is part of an on-going series in cybersecurity foundations. Check the cyber 101 article tag index from time to time for more content.

Anyone out there a fan of the Mission Impossible movies? I like them a lot but it always struck me as amusing how the protagonist agents could bypass elaborate security measures by simply showing up and wearing a disguise. In some ways, that's similar to IP spoofing attacks. Vulnerable and overly-trusting targets/applications might just assume that anything claiming to be from a specific source IP address, really is from there.

So what can we do about this? Performing a Reverse Path Forwarding (RPF) check is a good start. The basic idea here is that a receiving layer 3 networking device (like a firewall or router) asks a very simple question: Does it make sense that I'm receiving traffic from this source IP through the receiving interface? It sounds simple but it's a really good question to ask.

If we unpack this a little more, there are often a few levels of scrutiny that a security device (or router) could perform. FortiGates for example, have two options for RPF checks:

  • Feasible path - This RPF check mode will consider an incoming connection request valid as long as the source IP of the remote party is technically reachable/routable through the receiving interface. The path to the remote IP doesn't have to be ideal or the "best" route. It just needs to be technically feasible to reach the remote party through the processing local interface.
  • Strict - This RPF check mode is more picky. It only accepts an incoming connection for processing if the return path to the remote party is the "best" possible route. The rationale here is that traffic should always be traversing the absolute best path at all times. If it's not, then something is wrong (e.g. forged IP, incorrect upstream routing, etc).
đź’ˇ
Note: there's actually a 3rd RPF check mode called "loose mode". It's usually more applicable to routers. It accepts an connection if the source IP is reachable through any local interface (not necessarily just the receiving interface).

If you're curious, the Fortigate CLI config for RPF modes is as follows:

config system settings
    set strict-src-check [disable | enable]
end

Strict mode is OFF by default.

Cool right? It's certainly not the only security measure available for assessing the validity of a Source IP but every little bit counts :-). Check out the following resources for more info on this topic.

Reverse Path Forwarding (RPF) implementation and use of strict-src-check enable|disable
how Reverse Path Forwarding (RPF) is implemented on the FortiGate.It also explains how the VDOM-specific CLI setting 'config system settings -> set strict-src-check' modifies the RPF behaviour.Behaviour is highlighted with example. Reverse Path Filtering is defined in RFC 3704. ScopeForti…
Understanding Unicast RPF (Routers) | Junos OS | Juniper Networks
For interfaces that carry IPv4 or IPv6 traffic, you can reduce the impact of denial of service (DoS) attacks by configuring unicast reverse path forwarding (RPF). Unicast RPF helps determine the source of attacks and rejects packets from unexpected source addresses on interfaces where unicast RPF is enabled.
Security Configuration Guide: Unicast Reverse Path Forwarding, Cisco IOS Release 15M&T - Configuring Unicast Reverse Path Forwarding [Support]
Security Configuration Guide: Unicast Reverse Path Forwarding, Cisco IOS Release 15M&T-Configuring Unicast Reverse Path Forwarding