Quite a journey down the networking rabbit hole.
I started by reporting a minor UI bug in one of their webpages, which they quickly accepted and escalated (they even threw me a 10$ credit on my account, which was very cool).
At first I wasn’t able to ping my two linode instances via private IPs. I opened a ticket and the linode support replied with an amazing well documented response. Ultimately it boiled down to I should reboot my instances for the private IPs to work… :big_oof:
I tried some IPsec stuff and open vpn because those are build into the UDMPro UI, but they weren’t working. I assume I was doing something wrong, but configuring ipsec is quite a hassle. A similar story with Open VPN, most of the one click stuff is geared toward proxing my device traffic out linode, rather than sending traffic from the public back to my private subnet. Again, I’m sure it’s a quick fix, if you know what you’re doing, but I don’t.
Next I gave wireguard a try. I’ve heard good things about it, but it wasn’t built into the GUI of my UDM Pro, so I didn’t start there. Man was it easy to get going. The documentation is concise and straight to the point, and they lean so much on standard linux networking stuff, a great experience.
I’ve got my linode wireguard vpn instance stood up, and I’m able to connect to it’s private IP from my home network. Furthermore, I’m able to proxy through it to access my other linode instances via private ips (more on that later).
While working on this, I found I was able to persist containerized applications on my UDM pro, so I added a user space wireguard-go daemon, to create and manage the connection and restart with the box. It also plays nice with ddns.
Most of that work was done in boostchicken/udm-utilities I just had to spend some time doing configuration. Once I understood, what was going on in the boostchicken project, I went ahead and moved the cloudflare-ddns container to my UDM, and I contributed that work back up to boostchicken in this pull request:
Now, back to the wireguard networking stuff. I spent more time than, I’m comfortable admitting attempting to connect from a second linode instance, back down to my home network, via the wireguard vpn instance. I’m not a networking guy, so I didn’t have much confidence in what I was doing, but I know how to use tcpdump, and ping so I went for it. I learn a lot about modern linux netoworking commands and a bit about systemd along the way. (I’m very happy I don’t need to know how to use
iptables to get stuff done). My test box was setup with a static route for my home subnet but nothing seemed to leave the box. Ping the wireguard vpn directly? no problem. Ping the test box from the home network? no problem. Ping home network from test box? nothing. It was like my pings were going to the network equivalent of
I considered opening a ticket, as my other linode ticket was handled amazing, but lot of duck duck go searches finally yielded this thread:
Basically, what I wanted to do was not allowed.
I suspect the solution will be to simply have my other instances all join in a wireguard network, but I haven’t made it that far yet. I’ve also signed up for the Linode vlan beta, which will probably simplify and cost cut my networking between instances in the long run.
A very educational weekend it was.