We're working around this CVE in WireGuard's wg-quick(8) with a rule something like:
iptables -t raw -I PREROUTING ! -i wg0 -d 10.182.12.8 -m addrtype ! --src-type LOCAL -j DROP
where wg0 is the WireGuard interface and 10.182.12.8 is the local IP of the interface. This says to drop all packets that are sent to that IP address that aren't coming from the WireGuard interface. And it's done very early in netfilter, in the "raw" table.
I don't like having to use iptables in wg-quick(8), and so Willy Tarreau and I have been discussing a deeper kernel-level fix, which should be posted to netdev@ sometime soon.
Won't this break the use case of using Wireguard as a gateway to a private subnet, in the typical many-clients-one-server VPN setup?
For example, suppose I have a private physical subnet 10.12.0.0/24 (perhaps in an AWS VPC).
I want to allow clients to access to these private hosts using a Wireguard VPN, so I set up a VPN with all clients having IPs from the 10.34.0.0/24. Because I want these clients to have access to the private physical subnet, so each client's config has
AllowedIPs = 10.34.0.0/24, 10.12.0.0/24
Which adds both subnets to each client's routing table.
I add a new route for the VPC to send all packets destined for 10.34.0.0/24 to the central Wireguard "server", thus the Wireguard server acts as a gateway between the virtual 10.34.0.0 subnet and the physical 10.12.0.0 network.
The packets originating from the 10.12.0.0/24 hosts are not local, but I definitely want to route them onto the virtual 10.34.0.0/24 network.
I don't think the filter quoted in parent would stop this. In your example what it would stop is clients in 10.12.0.0/24 from connecting to the IP of the wireguard server itself (but not clients it routes to) on the 10.34.0.0/24 network (but not its IP on the 10.12.0.0/24 subnet).
Yea... not nice at all. And now we'll probably have to simultaneously support nftables. This isn't a route I really want to go down. Suggestions on alternatives are welcome.
1. Does encouraging ORCHID addresses reduce the impact of enumeration attacks?
2. Linux at least has controllable behavior for cross-interface IP reachability, in arp_filter/arp_announce/arp_ignore per interface sysctls, and ip address scope, as exposed by iproute / netlink. Perhaps its more proper for VPN addresses to be a scope 'link' address, instead of a scope 'host' address. Maybe a 'vpn' scope of some sort could be defined in future kernels, but I'm uncertain what that would do that a scope link address does not?
How plausible is it to sidestep iptables and inject the rules yourself directly to the kernel's interface? That gets rid of the dependency on a tool which adds friendliness you don't need plus a lot of baggage.
It seems as though (correct me if I'm wrong) the CVE requires an attacker to know or guess the target's IP on the VPN, they'll find out if they're right but they don't get a hotter/colder type feedback. So that opens the possibility to play a randomisation game. On IPv4 this is a very marginal benefit. But if a WireGuard client has been given a random 64-bit suffix for some particular IPv6 subnet then unless I misunderstand the attacker needs to probe all such suffixes until they find the correct one, and they can't realistically do that even on a fast network. If I'm right that's a pretty good mitigation (on IPv6).
Yeah, a random v6 address is not guessable, really.
But for v4? Start your search with private networks (10./8, 192.168./16, etc) and just enumerate /24s from .1, .2, .3 and I expect more often than not you'll do much better than chance.
I don't like having to use iptables in wg-quick(8), and so Willy Tarreau and I have been discussing a deeper kernel-level fix, which should be posted to netdev@ sometime soon.