←back to thread

67 points xlmnxp | 9 comments | | HN request time: 0.001s | source | bottom
Show context
eastabrooka ◴[] No.45666781[source]
Its 2025, Just use Tailscale.
replies(1): >>45666830 #
lucideer ◴[] No.45666830[source]
If you're running a homelab, the likelihood that you're interested in removing cloud-dependencies from your stack is above average. If that's the case, Tailscale is out.

Tailscale is just an added unnecessary external dependency layer (& security attack surface) on top of vanilla Wireguard. And in 2025 it's easier to run vanilla Wireguard than it's ever been.

replies(4): >>45666870 #>>45667234 #>>45670582 #>>45672775 #
1. aspenmayer ◴[] No.45666870[source]
Also, Headscale exists.
replies(1): >>45666969 #
2. lucideer ◴[] No.45666969[source]
I haven't tried Headscale but isn't it more complicated than Wireguard?

The selling point of Tailscale is that they simplify Wireguard UX by adding a proprietary control server - this adds complexity to the stack (extra component) but simplifies user experience (Tailscale run the control server for you).

Headscale seems like it's complicating the stack (adding an extra component) as well as complicating the user experience (you have to maintain two components yourself now instead of just the one Wireguard instance).

Granted I presume the Headscale control server might simplify management of your Wireguard instance but... you're still maintaining the control server yourself.

replies(3): >>45666998 #>>45667111 #>>45675246 #
3. aspenmayer ◴[] No.45666998[source]
It likely does add some complexity, though it’s relative. Self-hosting is always going to have some overhead. Managing WireGuard servers and clients and associated keys etc is probably the part that is most annoying, so I can see how it might be easier to throw that over the fence to Headscale even though it is introducing another dependency.

I was speaking more to doing it all in-house, versus outsourcing things to Tailscale, a third party not fully under one’s control, even if they act of behalf of the user. I think I largely agree with what you said.

replies(1): >>45667151 #
4. reedf1 ◴[] No.45667111[source]
It's much simpler to babysit a service than to manage a relatively higher risk thing like generating, rotating and communicating public keys between all of the nodes in the network.
5. lucideer ◴[] No.45667151{3}[source]
Fwiw I bought an Asus router that came with Wireguard pre-installed & has a nice management UI. It handles client onboarding via a simple QR code that integrates with the Wireguard mobile app - even my mother had no issue setting it up.

Buying hardware is an investment (& not something everyone can do) but I've really never understood the point of the control server from the perspective of an open-source self-hoster (for a business like Tailscale it makes sense as it introduces an element of control, user dependency & likely analytics of some value).

There's still a lot that can be done to improve Wireguard's UX but I think the Asus example proves it can be done well. Headscale seems to be doing the worst of both worlds (promoting an architecture & user-flow of a proprietary closed-source competitor, while still requiring CLI setup & instance maintenance). For example, it seems to me like it would be better for them to wrap Wireguard directly & integrate with the actual Wireguard mobile app instead of having people install proprietary Tailscale app on their phones to use your own open-source self-hosted control server.

replies(1): >>45667186 #
6. aspenmayer ◴[] No.45667186{4}[source]
There’s a cost with using Asus firmware instead of using stock OpenWRT, which might even be compatible with your router. Many Asus products are compatible, and may even be running OpenWRT themselves. The upshot is you get a nice GUI and a nice out of the box experience, but you’re also phoning home to Asus in small ways, just like one would be if they ran Tailscale.

I would agree that stock WireGuard is going to have the fewest dependencies, and I don’t mean to nitpick or be disagreeable because I do agree with you, that fewer third party dependencies is usually better than more.

The Asus-Merlin firmware is also nice, though the stock Asus firmwares have gotten pretty good and work for most folks for many use cases. I think VLAN config and tagging support might be one of the only features I wanted that stock Asus firmware didn’t handle when I used them last.

replies(1): >>45667858 #
7. lucideer ◴[] No.45667858{5}[source]
I'm on Merlin currently but I'm in the process of moving over to OPNSense for this exact reason.

However, while you can never really trust anything you run with internet access, I feel there's a fundamental line between an explicitly cloud-dependent service like Tailscale (e.g. a Tailscale control server outage incident would impact your home server access) compared to a fully self-hosted service that may or may not phone home if you don't put preventative measures in front of it, but will continue to function fine if you do put said measures in place.

The Asus mobile app is another potential concern but the Merlin browser UI is fine for most purposes.

replies(1): >>45671646 #
8. aspenmayer ◴[] No.45671646{6}[source]
> However, while you can never really trust anything you run with internet access, I feel there's a fundamental line between an explicitly cloud-dependent service like Tailscale (e.g. a Tailscale control server outage incident would impact your home server access) compared to a fully self-hosted service that may or may not phone home if you don't put preventative measures in front of it, but will continue to function fine if you do put said measures in place.

This is why I mentioned Headscale in the first place. It’s not for everyone or every use case, but it’s good that it exists, on the whole.

9. ◴[] No.45675246[source]