[HN Gopher] Understanding modern Linux routing (and wg-quick)
       ___________________________________________________________________
        
       Understanding modern Linux routing (and wg-quick)
        
       Author : EntICOnc
       Score  : 55 points
       Date   : 2022-07-26 17:57 UTC (5 hours ago)
        
 (HTM) web link (ro-che.info)
 (TXT) w3m dump (ro-che.info)
        
       | anonymousiam wrote:
       | "Fun fact: wg-quick uses the same numbers for the table and the
       | fwmark: 0xca6c is just 51820 in hexadecimal."
       | 
       | An additional "fun fact" is that 51820 is also the default port
       | number used by WireGuard servers.
        
       | rubatuga wrote:
       | It's kindly explained on the actual WireGuard page as well:
       | 
       | https://www.wireguard.com/netns/
        
         | endre wrote:
         | and it is mentioned on the blogpost as well. :)
        
       | VTimofeenko wrote:
       | I prefer the namespace approach with wg, as it becomes explicit
       | and easier to use with services through JoinsNamespace. The
       | routing inside the namespace is just using the main table.
       | 
       | This also allows to isolate the DNS queries by bind-mounting
       | nsswitch.conf and resolv.conf as well as manage the isolated
       | firewall for the namespace.
        
       | gxt wrote:
       | Anybody working on an enterprise bundle and support package for
       | wireguard? All "enterprise" vpn solutions I've had to touch in
       | the past 10years are flaky at best.
        
         | wswope wrote:
         | Does tailscale match what you had in mind?
        
       | jandrese wrote:
       | > 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.
        
       ___________________________________________________________________
       (page generated 2022-07-26 23:00 UTC)