Written 4 June 2024
Here on the eve's eve of the 80th anniversay of D-Day, I find myself just outside Normandy for work. Having been on the road a lot the past few months, there have been many cases where it would have been handy to have more than the 5 devices allowed by my provider. Their ToS is rather open ended, with no issues regarding hiding multiple devices behind my travel routers and home routers. However, it's easy to blow through 5 devices between my phone, home router, laptop, steam deck, and backup travel router. One way around this was to make that travel router a mullvad device. This is a problem when the travel router doesn't always work because of shoddy infrastructure in the backwaters of...every country (Or just a regular hotel).
Well, I still have multiple VPS, including one based in the US for US Internet purposes. So, step 1 was transferring my home wireguard interface for my YoHo VLAN to the VPS. That's easy. Just cp ~/mullvad.conf /remote-mount/wireguard/ and wq-quick it up. And look at that...we're locked out of the server. :(.
By default, wg-quick will modify the routing table to route the AllowedIPs portion of the config file. If that is 0.0.0.0/0, then it will modify the default route to be that wireguard interface. This, of course, led to comms only going in and out of the wireguard interface. Nice thing about a VPS is that I can VNC into it from the provider's browser and turn off the interface.
Wireguard is great, and I really enjoy using it. But finding all the options for the config file can be difficult, especially since the website hasn't really been updated beyond "Check out this neat new protocol" in years. Clearly, I'm an idiot who doesn't read the man pages. But actually, I am an idiot who does read the man pages, and the thing we need is not in the config file format section. Oh wait, here they are in the wg-quick manpage.
Thankfully, a smarter person than I has compiled a fairly comprehensive, unofficial, documentation repo with example called Unofficial Wireguard Documentation. Here, we find the Table entry in the Config Reference portion of the docs. This is simply pulled from the man pages, but all in one place, instead of spread across 4 or 5 man page. All we need to do, it turns out is add Table = off to disable the automatic route additions. With that, we have a commercial VPN interface I can use for egress of my devices.
As noted in the Wireguard VPN write up, I already have an ingress interface for all my devices and it's been running faithfully for nearly a year. All that's left is making traffic flow from ingress to egress while retaining access to home IPs. A little of routing magic is all we need for this:
$ ip route add default via [egress interface IP] dev wg1 table vpnusers
$ ip rule add 10.10.1.0/24 dev wg0 table vpnusers
$ ip route add 192.168.0.0/24 dev wg0 table vpnusers
$ ip route add 10.10.1.0/24 dev wg0 table vpnusers
And that's it. A quick check to my VPN providers curl endpoint for testing from a client shows I am connected through their network. Bonus nachos, I can use Firefox to proxy my connection out any server location, which goes the same for any computer connected to it.