Remix.run Logo
sevg 19 hours ago

I've always been slightly puzzled about why there isn't an easy built-in way to tunnel all traffic (ie, AllowedIPs = 0.0.0.0/0, ::/0) EXCEPT for some specific IPs. You end up having to programmatically generate a massive list of CIDRs that include everything except those specific IPs.

adamcharnock 19 hours ago | parent | next [-]

I agree that would be useful. I'm fairly sure it is because all the entries in `AllowedIPs` are just written as-is to the routing table, and the routing logic in the kernel (and most/all routers?) has no facility for 'does not match'.

Instead the solution would be to add a explicit route to state where the excluded CIDR should be sent to. That would would be more specific and would therefore be used for matching packets rather than the 0.0.0.0/0 (or whatever) routed pointed at the wireguard tunnel.

dgl 13 hours ago | parent [-]

To me this is actually one of the attractive aspects of Wireguard compared to some other VPNs, it doesn't try to manage everything within the tool and delegates to the host's normal routing mechanisms. However it still by default conflates AllowedIPs and the routing table -- you can actually separate them (Table=off with wg-quick) and then manually add routes.

irunmyownemail 10 hours ago | parent [-]

I agree completely with the sentiment, though I never actually mess with the routing tables.

tjoff 16 hours ago | parent | prev | next [-]

Calculator for the workaround: https://www.procustodibus.com/blog/2021/03/wireguard-allowed...

mrbluecoat 10 hours ago | parent | prev | next [-]

See https://github.com/tailscale/tailscale/issues/11717#issuecom...

graton 11 hours ago | parent | prev | next [-]

I think you need to use `Table = off`. With that you probably can get what you want.

rudasn 18 hours ago | parent | prev | next [-]

Can't you do that with a prerouting firewall rule?

Genuinely asking, never tried myself but seems plausible.

sevg 17 hours ago | parent [-]

There are a number of ways you could handle this, but none of them make wireguard seem user friendly for this use case.

If you're using WireGuard for point to point or to access a specific subnet, this isn't an issue.

But a common use case is to use WireGuard like you'd use Mullvad or Nordvpn and tunnel all traffic through it. And if you need exceptions for private address ranges or specific services, you end up having to generate a CIDR list (the WireGuard mobile app can do this for you if you check the "exclude private addresses" checkbox, but no such checkbox exists for wireguard tools on Linux, and it's a hardcoded list anyway), or add routes yourself, or fiddle with firewall rules.

rudasn 10 hours ago | parent [-]

Ah right.

Yeah it would be nice to have a negated allowed ips list, or adding an ! to signify "not this one". Wonder how difficult that would be to implement.

19 hours ago | parent | prev | next [-]
[deleted]
pm2222 11 hours ago | parent | prev | next [-]

ip route to blackhole works. ip rule works. ip/nftables works. tc works. ebpf works.

bsder 15 hours ago | parent | prev [-]

Or the reverse, most people have specific IPs that they'd like to route traffic through the VPN but mostly don't care about the rest.

Again, you wind up creating a huge list of exact IPs and creating the routing rules is a PITA.

akerl_ 14 hours ago | parent [-]

I don't understand. Having a specific list of IPs they want to route over Wireguard is the one that is easy today. It's the inverse (everything except these IPs) that's hard.