Hacker News Reader

>> Older VPN scripts used to override your default route in the main table when connecting to the VPN and restore it when disconnecting. Sometimes this wouldn’t work, and after disconnecting from the VPN you would be left without any default route at all.

> Isn't this the same problem the old VPN problems had though? If it fails to delete its two rules then your routing is still boned.

You're right, that's not the reason.

The real reason WireGuard doesn't use the traditional technique of replacing the default route is, straight from the horse's mouth https://www.wireguard.com/netns/:

  The most straightforward technique is to just replace the default route, but add an explicit rule for the WireGuard endpoint:

  # ip route del default
  # ip route add default dev wg0
  # ip route add 163.172.161.0/32 via 192.168.1.1 dev eth0

  This works and is relatively straightforward, *but DHCP daemons and such like to undo what we've just did, unfortunately*.

And right below that, is the reason WireGuard doesn't use the OpenVPN technique:

  So, 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:

  # ip route add 0.0.0.0/1 dev wg0
  # ip route add 128.0.0.0/1 dev wg0
  # ip route add 163.172.161.0/32 via 192.168.1.1 dev eth0

  This way, we don't clobber the default route. This also works quite well, *though, unfortunately when eth0 goes up and down, the explicit route for demo.wireguard.com will be forgotten, which is annoying*.

Both emphases mine.

> Instead it installs rules for 0.0.0.0/1 and 128.0.0.0/1, creating a rule that has slightly higher priority

More specific prefix isn’t slightly better, prefix length is one of the most significant rules of routing. This trick is quite common in networking - you point more specific routes to the main link and less specific to a backup. It the main link go down the specifics are getting withdrawn (some mechanism like dynamic routing should be in place for that) and the less specific route takes place, redirecting the traffic over the backup link.

I’ve done this myself many times (network engineer).

But tbh I see it as something of a “hack”. My gut tells me it’s not the right way for something like OpenVPN to do by default.

A metric would be better on 0/0, but I can see how the two /1 routes is gonna fix things in a whole bunch of edge cases.

>"For comparison OpenVPN doesn't use the ip rule infrastructure, instead it installs two rules directly on your routing table, but not for 0.0.0.0/0. Instead it installs rules for 0.0.0.0/1 and 128.0.0.0/1, creating a rule that has slightly higher priority than the default route ...."

I'm curious is the priority you referring to just longest prefix match by having two /1s, or are you referring to something else like setting a metric on the interface?

Yes, they are more specific routes than 0/0. In Linux can also have a metric, so if two routes are equal one can be preferred over the other. On networking devices you usually have administrative distance (different routing protocols) and metric (within one routing protocol).

Yes I understand how routing works and I referenced both of these things in my question. I was asking specifically which one the OP was referring to.

Wasn't it obvious what OP meant then?

Yeah, other VPNs do the same thing as wg-quick. Although they also may make a ton of more specific routes which take precedence over ones from wg-quick. It's fairly rare that routes don't get cleaned up, but a reconnect/disconnect or a reboot fixes it.

The host route to the VPN endpoint is sometimes there, but sometimes it's to a p-2-p interface, sometimes just the local device IP. Depends on the OS, tunnel interface, routes, etc.