uRPF, or Unicast Reverse Path Forwarding, is a router check that drops a packet when the interface it arrived on is not one the router would use to reach that source. In plain terms, strict uRPF wants the path out to be the same as the path in. When your routing is asymmetric, that check can kill the return path while your outbound probes still look fine, so the failure feels like a silent blackhole.
Strict mode versus loose mode
Strict mode is a solid anti-spoofing control on an access link that has one customer and one clear path. It is a poor fit on a multihomed edge, a VPS setup with two providers, or any host whose return path is not the inbound path. The public internet is full of asymmetry, and strict uRPF treats that asymmetry like spoofing. Loose mode is kinder: if the source is reachable through any interface, the packet is allowed. Loose mode still blocks addresses the router has no route for at all, which catches most garbage traffic. Feasible-path modes sit between those two. If you did not choose a mode, a default somewhere else may already be in force.
The failure we see most often is a multihomed VPS experiment sitting behind strict uRPF on a provider that rejects your other path. You can reach the world, yet half the world cannot reach you. MTR from your side looks clean, while MTR from theirs dies on the way back. Forward works and return fails. Check uRPF and the source address before you assume the guest OS is broken. A GRE tunnel whose inner source fails a strict check on the outer interface falls into the same class of ticket.
How the problem shows up
Only some sources die. You might lose a single customer, a single cloud region, or mail from one receiver. That pattern points to policy, not a kernel panic. Reinstalling the OS does not change a provider’s uRPF setting. Changing your source address to one the provider expects might help. Asking them for loose mode on that interface might help as well. Avoid announcing a more-specific route that pulls inbound traffic down a different path than your outbound default, because that mismatch is exactly what strict mode punishes.
What to do next
Spoofing controls are useful, and strict uRPF on a symmetric access link is appropriate. Strict uRPF across a diamond of transit is how a simple reachability issue turns into a long day of debugging under a “network is down” subject. If you run a single VPS with a default route through us, you are usually not the one enabling this check. If you speak BGP, you might be, or your upstream might be, so say which side you control when you open a ticket. Do not flip a sysctl inside the guest and call that uRPF. That setting is rp_filter, a related host filter, and it can blackhole you too if you stacked two NICs and a tunnel.
When only some paths fail, treat it as a reverse-path policy problem first. Gather MTR in both directions, note your source address and any tunnels, and ask whether strict uRPF is enabled on the inbound interface before you rebuild the server.
Tagged
Was this article helpful?
Be the first to rate this article.
