Reverse Path Forwarding (uRPF): the router's anti-spoofing check

Reverse Path Forwarding (uRPF) is a security mechanism used by routers to prevent IP address spoofing. When a packet arrives, the router checks if the source IP address in the packet can be reached via the same interface on which it arrived. If not, the packet is dropped as potentially malicious.

How Reverse Path Forwarding Works

When a packet enters a network, the router performs an RPF check to verify the source IP address. The core idea is simple: if the packet's source address cannot be routed back out through the same interface it came in on, then the packet may have been spoofed and should be dropped.

Why Reverse Path Forwarding Exists

Source IP spoofing allows attackers to hide their identity or launch reflection/amplification DDoS attacks. By dropping packets with suspicious source addresses, RPF helps mitigate these threats. BCP38 (RFC 2827) recommends network ingress filtering using uRPF to ensure that only legitimate traffic is allowed into the network.

Modes of Reverse Path Forwarding

There are three main modes of uRPF:

1. Strict uRPF: The source address must be reachable via the exact same interface through which the packet arrived. This mode is effective at catching spoofed packets but can drop legitimate traffic in asymmetric routing scenarios.
2. Loose uRPF: The source only needs a route somewhere in the table, allowing for any interface to be used. This mode is more permissive and handles asymmetric routing better.
3. Feasible-Path uRPF: Accepts if the source is reachable via any valid/alternate path. It strikes a balance between strictness and flexibility.

The Gotcha: Asymmetric Routing

Strict uRPF can silently drop legitimate traffic in asymmetric routing scenarios, which are common in multihomed networks or those with load-balanced WAN links. This issue ties directly to the asymmetric-routing warning in the routing basics doc.

Implementation Details

FortiGate

• Default Behavior: Performs RPF checks by default.
• Common Issue: Adding a firewall policy and route to the destination may still drop traffic due to an invalid reverse route.
• Fixes:
  • Add the return route.
  • Disable RPF per-interface (the "asymmetric routing" toggle or src-check disable).

Linux

• rp_filter Sysctl: Controls how uRPF is implemented. Values: 0 = off, 1 = strict, 2 = loose.
  • Common Issue: In policy-routing, multi-WAN, WireGuard, and container/VPN setups where paths are asymmetric, rp_filter=1 can silently drop traffic.
  • Fixes:
    • Set rp_filter to 2 (loose) or 0 and rely on explicit firewall rules.

Cisco/Juniper

• Configurations:
  • Cisco: ip verify unicast source reachable-via rx for strict, any for loose.
  • Juniper: RPF-check configuration.

Multicast RPF

Originally, RPF was used in multicast routing to prevent loops. A multicast packet is accepted only if it arrived on the interface that is part of the reverse path toward the source. This mechanism ensures loop-free multicast by reusing unicast routes.

Best Practices

• Single-Homed Edges: Use strict uRPF.
• Asymmetric Routing or Multihomed Networks: Use loose or feasible-path uRPF.
• Linux: Set rp_filter deliberately per interface (2 for policy routing/multipath/VPN, not the reflexive 1).

When a firewall or router "has the route but drops the traffic," check the reverse path first.

flowchart TD
  P[Packet arrives on an interface] --> Q{Does the route back to its source use this same interface}
  Q -->|Yes| A[Accept the packet]
  Q -->|No in strict mode| Dr[Drop as likely spoofed]