New, leaner network setup: removing NATs, and ditching Tailscale

I’ve read somewhere that Intel for many years has been doing a tick-tock model in his development cycle. Thankfully, it had nothing to do with the Chinese data-hoarding, addiction-inducing short video app, but rather with how they improved their products. First was the tick, creating a new machining process, and then the tock, expanding and perfecting it. More on the whole cycle can be read on its Wikipedia page.

I’m writing about it because I feel I have been something similar with my homelab. First is the tick, adding new things, new processes, new complexities, and after a while comes the tock, removing what I find unneeded, cumbersome, things I do not use, and attempting to simplify my setup as much as possible.

This blog post is about the latest tock stage, one that made my homelab network setup much, much leaner. It’s also about how one decision leads to another, and how even a small step opens new possibilities.

Before

The last tick stage left me with most of my self-hosted services being behind a triple NAT.

The first level is my Mikrotik RB3011 router that is the entrypoint to my flat’s network. I don’t use an ISP provided router/modem, because the ISP provides me with Internet access via a twisted pair cable coming through a wall straight into the flat, and with auth being done by PPPoE.

The second level of NAT is my WiFi mesh/bridge setup which I described in this blog post. I know there are ways to make a WiFi access point not do NAT, but this is a mesh setup, and a) it is absolutely mission-critical for me and my wife to do work from home, and b) it will only last until we move to the house, in the house there’s going to be a single ceiling mounting AP. I already made plans with the electrician to leave one twisted pair hanging from a hole in the ceiling, and I’ll mount a Mikrotik cAP ax and power it over PoE. So for the time being, the bridge stays.

The third level of NAT was my LXD setup with the default bridge network. LXD by default puts all running containers and VMs on its own bridge that only the host can access. I exposed the services using a static route, as shown in this video, but that still left me with another level of network obfuscation.

To access those services remotely I was using Tailscale. I installed Tailscale both on the host to reach the non-lxced services, and also on every container to be able to also reach them. While it work, it felt… incorrect. And the number of Tailscale clients grew with every new container, each one of them requiring installation and configuration.

Removing These NATs

The first change happened because of our upcoming move to a new house. As we are getting ready for it, the living room has been slowly turning into a place for storing things we already bought for the new place, like a set of garden furniture we found on a very good sale. The living room is also where the router is located, because there the ISP cable comes from the wall. And so I thought, with that room already becoming basically storage, moving my homelab there won’t make much of a difference. So I moved my main server/NAS there, and now the server is connected straight to the RB3011, removing one layer of NAT. Dumping the WiFi part means also the Internet speeds jumped a lot. And I have more space under my desk.

The second change was with my LXD setup. Yes, I know, I will move to Incus, but not yet, I have it on my list. I recently learned about the MACVLAN network type in LXD, which puts the containers on the same DHCP address pool as the host, basically removing the NAT. The downside is that the containers cannot talk to the host, but in most cases I can live with that, they do not need to so. With the exception of the one running my monitoring stack, Grafana and InfluxDB, which needs to get metrics from the host, so this was stays on the default network.

The rest of the containers/service I moved to MACVLAN, so that my Forgejo, or Nextcloud are right in the same LAN namespace as the other machines. Setting up MACVLAN is very well described in this blog post.

This means that right now I have a single, flat, LAN network namespace. And that opened new possibilities.

Removing Tailscale

In the beginning of the post I mentioned how I have been using Tailscale to punch through all those levels of network address translation. But now that problem was gone. And the other thing is with my solar webserver, I have renewed interest in Wireguard. I really like how clean it is, and how it can be configured in the command line, or in automation tools like Ansible (soon there will be a post on Ansible!). And finally, it can be configured straight on a Mikrotik router, so no need to install it on all clients and containers. Truly a great piece of technology.

So I decided to move from Tailscale to Wireguard.

This is not the post to talk about my Wireguard setup in detail, so in short:

Btw, one of the problems I always have when writing blog posts is to decide how deep I want to go in talking about my actions, provide the whole configuration process, or just talk briefly about the ideas.

I already have a VPS with Wireguard, the one handling my solar website. This is the publicly reachable hub that all my WG clients can talk to and know how to reach it.

Then, I have Wireguard configured on my Mikrotik RB3011 router, so that every machine in the LAN can talk to that VPS via Wireguard. And vice Versailles, the VPS can reach any machine in the LAN, thanks to that flat network topology I achieved in the previous step.

Finally, I installed WG clients on my phone and my laptop, the only machine I take away from my home LAN. This allows me to reach my local services from any place through the secure connection of the VPN. And finally 2, that VPS works as a relay, forwarding traffic between different clients.

And to quote the great American poet, Billy Mays, wait, there’s more! With Wireguard, the LAN clients keep their local IP addresses even when I talk to them through the VPN from away, so I don’t have anymore that issue that I had with Tailscale, to keep two different set of bookmarks for my services, one with the internal address, and one with the Tailnet hostnames.

Another step in Degoogling

I removed the Tailscale clients from all of my devices and closed the account. Which also means that I can close my secondary GMail account that I have been keeping only because it was how I logged into Tailscale. I know you can login to Tailscale with a custom self-hosted OIDC service, but I never came around to do it. Anyway, one less Google service for me. I will have another blog post on my process of Degoogling, I would say I am something like 90% done overall, but as always, the last 10 percent are the hardest.

Bottom line

This post has been, as I feel it, about how small decisions in the homelab can lead to larger changes, and how everything is in a way connected to each other.

I am very happy with my new, much leaner, networking setup, and in a way, for me it is another step of preparation for my new house. I can’t wait to also get rid of that WiFi bridge, it has been frustrating me in more than one way.

Bottom line 2

There is another one thing I need to work out now. Tailscale has been the source of TLS certificates for my Nextcloud (I wrote about it here), and with removing it I lost that functionality. But the great people of the Fediverse already suggested possible solutions, and I am very thankful! I will work on it somewhere in the near future when I feel like tackling this issue from the list of all the other issues with my homelab :) Here is the Fedi thread.

Thanks for reading!

If you enjoyed this post, please consider helping me make new projects by supporting me on the following crowdfunding sites: