Support strict reverse path filtering #682

ncf commented 2026年02月08日 14:18:10 +01:00

Strict reverse path filtering is a security measure that drops incoming packets unless they would be routed out of same the interface they came in from. This is currently not compatible with eduVPN's routing, because incoming WireGuard packets are received on the WAN interface but would be routed through the WireGuard interface if the endpoint is included in AllowedIPs. As a result, the docs mention (here and here) that one should loosen reverse path filtering in environments where it is strict by default.

It would be nice to support strict reverse path filtering. wg-quick does this by saving the fwmark for WireGuard connections as the connection mark and restoring it for incoming packets. It then enables net.ipv4.conf.all.src_valid_mark so that the mark is taken into account for reverse path filtering. If one uses the rpfilter netfilter module instead, one can use --validmark to the same effect (NixOS enables this by default).

Maybe this is something to be fixed in NetworkManager directly.

Strict reverse path filtering is a security measure that drops incoming packets unless they would be routed out of same the interface they came in from. This is currently not compatible with eduVPN's routing, because incoming WireGuard packets are received on the WAN interface but would be routed through the WireGuard interface if the endpoint is included in AllowedIPs. As a result, the docs mention ([here](https://docs.eduvpn.org/client/linux/support.html#connecting-to-wireguard-vpn-over-ipv6-blocked-by-firewalld) and [here](https://docs.eduvpn.org/client/linux/installation.html#nixos)) that one should loosen reverse path filtering in environments where it is strict by default. It would be nice to support strict reverse path filtering. `wg-quick` [does this](https://github.com/WireGuard/wireguard-tools/blob/0b7d9821f2815973a2930ace28a3f73c205d0e5c/src/wg-quick/linux.bash#L238-L241) by saving the fwmark for WireGuard connections as the connection mark and restoring it for incoming packets. It then enables `net.ipv4.conf.all.src_valid_mark` so that the mark is taken into account for reverse path filtering. If one uses the rpfilter netfilter module instead, one can use `--validmark` to the same effect (NixOS enables this by default). Maybe this is something to be fixed in NetworkManager directly.

ncf commented 2026年02月08日 15:07:28 +01:00

NetworkManager actually already does this if ip4/6-auto-default-route is enabled, but eduVPN does not enable that and sets up routing manually instead. It would be good to rely more on NetworkManager for this. If something cannot be done then changes should be made upstream.

NetworkManager actually [already does this](https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2158) if [`ip4/6-auto-default-route`](https://networkmanager.dev/docs/api/latest/settings-wireguard.html) is enabled, but eduVPN [does not enable that](https://codeberg.org/eduVPN/linux-app/src/commit/62b3a3538532b1b19a47648e60c9ffd367ef837c/eduvpn/nm.py#L599-L601) and sets up routing manually instead. It would be good to rely more on NetworkManager for this. If something cannot be done then changes should be made upstream.

jwijenbergh commented 2026年02月09日 15:20:45 +01:00

we can't use NetworkManager's routing as it automatically adds a suppress_prefixlength 0 rule, which allows all non default route traffic from the main routing table. This is insecure as it does not protect against attacks like tunnelcrack/tunnelvision that abuse this behavior to bypass the VPN using DHCP static routes.

we can't use NetworkManager's routing as it automatically adds a suppress_prefixlength 0 rule, which allows all non default route traffic from the main routing table. This is insecure as it does not protect against attacks like tunnelcrack/tunnelvision that abuse this behavior to bypass the VPN using DHCP static routes.

ncf commented 2026年02月09日 16:50:08 +01:00

Was this issue raised upstream? This seems like something that should be fixed in both NetworkManager and wg-quick, if it is really a security risk.

Was this issue raised upstream? This seems like something that should be fixed in both NetworkManager and wg-quick, if it is really a security risk.