Hello,
I would like to ask, why is rp_filter disabled by default on openwrt? Is it just because of linux default?
I understand that there may be reason to have it off on some systems, but shouldn't default settings disable rp_filter?
i dont feel like i fully understand your question...
but, it seems like the interface was/is bonked
also its a rather non-trivial concept and would probably create a lot of breakage if default-on.
idk if there is a reason tbh
any1?
1 Like
Setting rp_filter to '1' (strict mode) breaks openvpn, for example.
2 (loose mode) works fine though.
The 3 values that can be set for the key rp_filter are:
0 No source address validation is performed and any packet is forwarded to the destination network
1 Strict Mode as defined in RFC 3074. Each incoming packet to a router is tested against the routing table and if the interface that the packet is received on is not the best return path for the packet then the packet is dropped.
2 Loose mode as defines in RFC 3074 Loose Reverse Path. Each incoming packet is tested against the route table and the packet is dropped if the source address is not routable through any interface. The allows for asymmetric routing where the return path may not be the same as the source path
Does using mode 2 make any sense if one of the interfaces is a default gateway? I mean, all addresses are routable through that interface?
I guess, no?
Mode 2 checks if the packets source address can be routed through any interface, so when there is a default route, this check will always pass?
However it should be possible to enable strict mode on all interfaces by default with:
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
And enable loose mode on "prolematic" interfaces
net.ipv4.conf.ovpnc0.rp_filter = 2 # OpenVPN Client
After checking the source code, rp_filter being off should be linux kernel default. It's written in the kernel Documentation, in net/ipv4/devinet.c, and no explicit changing of that in the openwrt base system code.
1 Like
I agree here. It came from linux kernel.
I would disable it but I'm curious for the openvpn issue.
deploying rp_filter is good network security practise and also part of CVE-2019-14899 and mitigation
on virtual interfaces such as OpenVPN or WG .rp_filter = 2 produces martians, that are only being visible with log_martians = 1, however .rp_filter = 1 works fine for those interfaces
this sound strange, other sources (like openvpn docs) report that problem appears when rp_filter is '1' and recommend setting it to '0' or '2'.
but it seems thtat it's a trick fo get old connections/services working when connecting to VPN would break them.
Sure, got mixed up with the numerics, loose works for those virtual ifaces whilst strict produces the martians.