What is rp_filter and what is it used for?

In the world of Linux and networking technologies, there are many subtle but critically important kernel settings. One such setting is rp_filter. This parameter, often overlooked, plays a key role in network security and correct packet routing. Let’s explore what it is, how it works, and why understanding it is essential for every system administrator.

What is rp_filter?

rp_filter stands for Reverse Path Filtering. It’s a Linux kernel mechanism that checks incoming network packets to verify whether they arrived on the interface through which a reply to the sender’s IP address would be routed.

Simply put: when a packet arrives on a network interface, rp_filter checks whether the server would send a response to the sender’s IP address through the same interface the packet came in on.

Imagine this analogy: You receive a letter with a return address of “Lenina Street, house 5.” Your post office checks: if you were to send a reply to “Lenina, house 5,” would you use the same post office that the original letter came through? If yes, everything is fine. If not (e.g., “Lenina, house 5” is in another city and uses a completely different post office), the letter is considered suspicious.

What is rp_filter for? (Main purpose: Anti-spoofing)

The main goal of rp_filter is to protect against IP spoofing. IP spoofing is a technique where an attacker forges the source IP address of network packets to impersonate another computer. This can be used for:

• DDoS attacks: Hiding the true origin of the attack.
• Bypassing network filters: Masquerading as a trusted node.
• Man-in-the-Middle attacks: Intercepting and modifying traffic.

When rp_filter is enabled, it rejects incoming packets whose source IP address doesn’t match the expected reverse route. This ensures that packets your server receives genuinely come from where they claim to originate—or at least that the return path to the sender via that interface is “valid” according to your routing table.

rp_filter modes of operation

rp_filter is configured per network interface (for example, eth0, eth1), and also via the global keys all and default (how they interact is explained below). The parameter can take one of three values:

• 0 (Disabled): Disabled. Reverse path filtering is not performed. All packets are accepted regardless of the reverse path. Not recommended for most environments, as it makes the system vulnerable to spoofing.
• 1 (Strict mode - strict checking): Enables strict RFC3704 mode. The system checks that a reply to the incoming packet would be sent only via the same interface the packet arrived on, and that this would be the best route to the packet’s source. If not, the packet is dropped.
  • Advantages: Maximum protection against spoofing.
  • Disadvantages: Can cause issues in complex network configurations, such as asymmetric routing (when incoming traffic comes one way and outgoing traffic goes another), and when using some forms of load balancing.
• 2 (Loose mode - loose checking): Enables loose RFC3704 mode. The system checks that a reply to the incoming packet could be sent via any interface on this server. If there is at least one route to the packet’s source, the packet is accepted.
  • Advantages: A good compromise between security and flexibility. Provides spoofing protection while allowing asymmetric routing and other complex network scenarios.
  • Disadvantages: Less strict protection compared to mode 1.

Where is it and how to configure it?

rp_filter parameters are located under /proc/sys/net/ipv4/conf/. You can see them for each interface and for all interfaces together:

• /proc/sys/net/ipv4/conf/all/rp_filter (global value: when checking a packet the kernel compares it with the interface value and takes the greater of the two)
• /proc/sys/net/ipv4/conf/default/rp_filter (value that will be assigned to interfaces created after changing the parameter)
• /proc/sys/net/ipv4/conf/<interface_name>/rp_filter (for example, /proc/sys/net/ipv4/conf/eth0/rp_filter)

Check the current value (for example, for eth0):

cat /proc/sys/net/ipv4/conf/eth0/rp_filter

Change the value temporarily (until reboot):

echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth0/rp_filter

Change the value permanently (persisting across reboots):

Use sysctl. Open or create a configuration file (for example, /etc/sysctl.d/99-rpfilter.conf):

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
# If you need a separate value for a specific interface:
net.ipv4.conf.eth0.rp_filter = 1

Comments in sysctl.d files must be written as a separate line starting with # or ;. An inline comment at the end of a value line is not allowed: text after # will be considered part of the value, and the parameter will not be applied.

Then apply the changes:

sudo sysctl -p /etc/sysctl.d/99-rpfilter.conf

The command sudo sysctl -p without arguments reads only /etc/sysctl.conf. To apply all files from /etc/sysctl.d/, /run/sysctl.d/ and /usr/lib/sysctl.d/, use:

sudo sysctl --system

If multiple files set the same parameter, the value from the file whose name comes last alphabetically takes effect, so it’s convenient to place your settings in a file with the 99- prefix.

all vs interface: which value applies

A common mistake is to assume that net.ipv4.conf.all.rp_filter sets a “default” that can be overridden on a specific interface. This is not the case. According to kernel documentation, when checking a packet that arrived on an interface, the maximum of the two values is used: conf/all/rp_filter and conf/<interface>/rp_filter.

Practical consequences:

• To loosen checking on a single interface (for example, set 2 on a tunnel with asymmetric routing), changing only the interface value is not enough: all must not be greater than the desired value. Usually people set all = 0 and specify the mode on each interface individually.
• To tighten checking everywhere at once, it is sufficient to raise all.
• The default key does not affect already existing interfaces — only those created later (tunnels, VLANs, container interfaces).

You can see what actually applies with a single command:

sysctl -a 2>/dev/null | grep '\.rp_filter'

On systemd-based distributions, the shipped file /usr/lib/sysctl.d/50-default.conf sets loose mode (2) for default and all interfaces, while intentionally leaving all untouched — it remains at the kernel default value 0. Therefore on such systems loose mode (2) actually applies, even though cat /proc/sys/net/ipv4/conf/all/rp_filter shows 0.

Configuration recommendations

• For most servers (single interface, no asymmetric routing): Use rp_filter = 1 (strict mode). This provides the best protection against spoofing.
  conf Copy

  net.ipv4.conf.all.rp_filter = 1
  net.ipv4.conf.default.rp_filter = 1

• For servers with asymmetric routing, multiple IPs on an interface, or complex network configurations (for example, load balancers, VPN servers, some virtual machines): consider rp_filter = 2 (loose mode). It provides a reasonable level of protection while allowing incoming traffic to arrive one way and outgoing traffic to go another.
  conf Copy

  net.ipv4.conf.all.rp_filter = 2
  net.ipv4.conf.default.rp_filter = 2

• If routing depends on packet marks (fwmark), for example when using policy routing via ip rule fwmark or transparent proxying, pay attention to the src_valid_mark parameter. When set to 1, the packet mark is considered during reverse path checking, and rp_filter works correctly when the mark is used for routing in both directions. When 0 (default), the mark is not considered. The same maximum-of-all-and-interface rule applies to src_valid_mark.
• Never use rp_filter = 0 unless you have very strong reasons and fully understand the risks.

An example where rp_filter often interferes is sending a subnet’s traffic through a remote server via a tunnel with policy routing; an analysis of such a setup is in the article Routing traffic from a local subnet through a remote server (IPIP + Policy Routing). Asymmetric routing with two providers is discussed in the article Redundancy of communication channels: Part 4 — Internet connectivity: BGP, DNS failover and CDN.

Conclusion

rp_filter is a powerful tool for enhancing your Linux server’s network security by protecting against IP spoofing. Properly configuring this parameter is critically important, especially in publicly accessible environments. Always start with the strictest mode (1) and loosen to 2 only if legitimate traffic breaks in complex networking setups. Remember: understanding kernel networking settings is key to a stable and secure infrastructure.