When I moved into my workshop, I obviously started thinking about some better network connections to home. When the NBN bumped up the network speeds and I started building the garden at the studio I knew I'd want the data from the workshop garden going into my homelab IoT system.

So most geeks can do a bit of networking, I've put together plenty of single subnet networks for home, work, remote and projects. While I'm a non-default settings type of person and will dive into DHCP, static host IP & DNS and basic vpn ingress, there's a level of IP routing complexity I don't often venture into. Let's say I'm much more of a Ubiquity rather than MikroTik kind of guy.

So this project is out on the edge of my networking skills, but some modern software has made it a lot easier.

I was originally thinking of using tailscale but in the lead up to actually starting the project, I discovered netbird . There was some evidence that the LAN to LAN thing was easier in netbird and the possibility of self-hosting completely in the future was appealing, so I thought I'd give it a go.

While I could have just run the software on some existing machines, I had a couple of low power industrial single-board computers spare, so I built two machines to just run netbird. All my machines have spaceship names, so I named these after two space stations from the Expanse universe Tycho and Medina. Tycho is in the solar system so that's the home machine and Medina station is beyond the rig, so that's the studio machine.

Netbird basically helps set up a WireGuard tunnel between the two machines so the networks on either end can talk to each other.

Getting netbird set up and routing traffic between the two networks was pretty easy actually. Configuring each network so clients were aware of the route was a bit more complicated. At home, it was pretty easy as I'm running a Ubiquiti EdgeRouter Lite, so it was easy to add a static route. In the workshop, the network is a subnet set up in a larger building-wide Unifi system, which I'm lucky enough to have enough access to configure. The solution here was to advertise the route via DHCP option 121. I had no idea that you could distribute routes via DHCP.

So the whole process was made a lot easier by having web searching LLM's like perplexity.ai to work through issues with. I still had a few wrong turns, and at one point I had my workshop machines unable to get to the internet, but still managed to fix and resolve things pretty quickly.