Linux VPN Replies Disappear? Check rp_filter and the Route

Requests leave the machine, the VPN peer answers, and the reply never reaches the socket. The tunnel is up, the peer logs show the packet being sent, and nothing in the application explains the silence. On Linux one of the usual suspects is reverse-path filtering: an incoming IPv4 packet can be rejected when source validation disagrees with the route the kernel expects for that source. Walking it in order tells you whether that is the cause or a coincidence. It also keeps you from disabling a security control to fix a missing route.

What source validation is deciding

The kernel checks whether a packet's source address is plausible for the interface it arrived on, by consulting the routing table for a route back to that source. If the reverse route points somewhere else, the packet can be dropped before any firewall rule or application socket sees it. That check exists to make certain spoofing patterns harder, and it is also why asymmetric and policy-routed designs run into it while every ordinary client on the same network works fine. Ordinary clients have symmetric routing, which is exactly what the check assumes.

The important word is plausible. The packet can be perfectly legitimate and still fail the check, because legitimacy is not what is being tested.

Read the effective mode, not one field

Three modes exist: disabled, strict and loose. Strict imposes a different route expectation than loose, and the global setting interacts with per-interface ones, so reading a single file can misdescribe what is actually in force. Read both, and read them on the interface that receives the reply rather than on the default route's interface.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.<iface>.rp_filter
ip route get <source-of-the-reply>

The route lookup in that third line is the part people skip. It tells you what the kernel believes about the source, which is exactly the input to the check.

Find the mismatch before changing the check

Work out why the reply arrives on that interface and whether its reverse route is supposed to differ. A policy rule that sends requests out one path while replies return on another is a legitimate design, and it is also the design that strict validation rejects. Marks used in policy routing can matter here too, since they change what the reverse lookup returns.

If the reverse route is simply missing, adding it fixes the cause rather than disabling a check. A missing route, a firewall rejection and a wrong traffic selector all produce the same visible symptom, and only one of them is about source validation.

Do not turn source checks off globally as the first response. That trades a specific diagnosis for a broad behaviour change you will have to remember later.

A selective adjustment you can defend

If a narrow adjustment is genuinely required, scope it to the interface that needs it, write down why, and put it in the configuration that owns that interface so it survives a reboot. Then retest the exact flow that failed, from the same source to the same destination, rather than a ping to something convenient.

Include a case that should still be refused. If that case now succeeds, the adjustment weakened more than the one path you meant to repair.

Keep IPv4 and IPv6 separate

A familiar-looking sysctl is not a policy for every address family. IPv6 has its own behaviour and its own settings, and a machine can be strict on one family and permissive on the other without anyone noticing until a specific destination fails. Check both if the workload uses both.

Record the mode, the interface, the route lookup output and the reason for the change in one place. The next person will find the setting and no explanation, and will either remove it or copy it somewhere it does not belong.