In addition, wg-quick appears to use the rule-based solution with multiple tables by default. As I understand it this should make Wireguard (with wg-quick) users on Linux immune to this attack. My default route sends traffic to my gateway, not my VPN:
default via <gateway ip> dev host0 proto static
So there's nothing for an attacker to do here. They could make themselves my gateway perhaps, but the `ip rule` would still send my traffic to Wireguard and the result would not be readable.
The issue described in the article is what happens if you take the most basic approach, which is described in the Wireguard article: "instead of replacing the default route, we can just override it with two more specific rules that add up in sum to the default, but match before the default". This is historically what OpenVPN has done, and it's vulnerable to this issue.
In general, rule-based solutions are good if they use fwmark, but this gives me pause:
> And finally we add a convenience feature for still accessing the local network, whereby we allow packets without the fwmark to use the main routing table, not the WireGuard interface's routing table, if it matches any routes in it with a prefix length greater than zero, such as non-default local routes. [https://www.wireguard.com/netns/#improved-rule-based-routing]
Doesn't that completely neutralize the protection against a DHCP server sending malicious routes or a gigantic subnet mask?
its just a default convenience feature from wg-quick, its not intended to be something that fits all usecases; on trusted networks split-tunneling like that makes lot of sense