3 ms·

> 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

> 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. wg-quick doesn’t have this problem, as it never messes with your main routing table. All it has to do when disconnecting is delete its two rules, and your default route is active again, Or you could even do that yourself with ip rule del. 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. 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 so it can leave the default in place and not get burned with NetworkManager decides to delete and re-add the default route for whatever reason. Not having the routes cleaned up after the VPN exits is usually not the problem, as they are tied to the TUN interface and get cleaned up by the kernel when that interface is destroyed anyway. The bigger issue is clients that forget to install the host route to the VPN endpoint. I see that error a lot and it always drives people crazy because their VPN client negotiates and connects properly, and then everything breaks for no obvious reason.

throwaway787544 4y ago
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.
bogomipz 4y ago
>"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?
- Hikikomori 4y ago
  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).
  - bogomipz 4y ago
    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.
    - Hikikomori 4y ago
      Wasn't it obvious what OP meant then?
allarm 4y ago
> 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.
- topranks 4y ago
  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.
occoder 4y ago
>> 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/ 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.

throwaway787544 4y ago

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.

bogomipz 4y ago

>"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?

Hikikomori 4y ago
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).
- bogomipz 4y ago
  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.
  - Hikikomori 4y ago
    Wasn't it obvious what OP meant then?

allarm 4y ago

> 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.

topranks 4y ago
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.

occoder 4y ago

>> 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/ 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.