Most active commenters
  • lucideer(6)
  • aspenmayer(4)

←back to thread

67 points xlmnxp | 17 comments | | HN request time: 0.209s | source | bottom
Show context
eastabrooka ◴[] No.45666781[source]
Its 2025, Just use Tailscale.
replies(1): >>45666830 #
1. 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 #
2. aspenmayer ◴[] No.45666870[source]
Also, Headscale exists.
replies(1): >>45666969 #
3. 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 #
4. aspenmayer ◴[] No.45666998{3}[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 #
5. reedf1 ◴[] No.45667111{3}[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.
6. lucideer ◴[] No.45667151{4}[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 #
7. aspenmayer ◴[] No.45667186{5}[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 #
8. fragmede ◴[] No.45667234[source]
It exists on a spectrum. Time for hobbies including homelabbing is limited, so while someone who's retired and has all the time in the world to tinker can go self host every last single thing, I'd bet that more people just want to be able to have something that works without a huge depency on the cloud. As long as the bits are on the hard drive in my basement, how the packets get routed around is less critical, to some people, I imagine.

Everybody's got their own set of beliefs and understandings, and they get to decide how they want their homelab to work.

For me, tailscale fits in just right. Others can come to their own conclusion based on how they feel about networking and points of failure and depency and all that.

9. lucideer ◴[] No.45667858{6}[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 #
10. bakugo ◴[] No.45670582[source]
Normally I'd agree with the philosophy, but I don't really see how you can say this about vanilla Wireguard in particular considering how involved it is, especially if you have more than 2 devices that you want to connect together.

Not only do you need to manually manage the keys for each device and make sure they're present in every other device's configuration, but plain Wireguard also cannot punch through NATs and firewalls without any open ports like Tailscale can, as far as I know.

Combine that with the fact that networking issues can be some of the hardest to diagnose and fix, and something like Tailscale becomes a no-brainer. If you prefer using plain Wireguard instead, that's fine, and I still use it too for some more specific use cases, but trying to argue that Tailscale is entirely unnecessary is just wrong.

replies(2): >>45673797 #>>45679682 #
11. aspenmayer ◴[] No.45671646{7}[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.

12. sneak ◴[] No.45672775[source]
Not really. Most things people run in homelabs have tons of cloud dependencies. Try running Home Assistant offline, for example.
replies(1): >>45673059 #
13. lucideer ◴[] No.45673059[source]
I run home assistant offline. I've never encountered any issues, except for the little weather widget that comes enabled by default not working.

I know there's plenty of HA integrations that require some cloud service but the core application is very offline-friendly...

14. lucideer ◴[] No.45673797[source]
> trying to argue that Tailscale is entirely unnecessary is just wrong

Tailscale is great if it meets your requirements, & it probably does for most - I wasn't arguing that at all. Only that it won't be an option for everyone: in particular a non-tiny subset of home server hosters.

15. ◴[] No.45675246{3}[source]
16. Capricorn2481 ◴[] No.45679682[source]
> but plain Wireguard also cannot punch through NATs and firewalls without any open ports like Tailscale can, as far as I know

I could be wrong, but I think Tailscale just does what you can do on Wireguard, which is `PersistentKeepAlive`. It lets a wireguard client periodically ping another to keep the NAT mapping open.

replies(1): >>45684399 #
17. bakugo ◴[] No.45684399{3}[source]
What that does is allow existing outgoing connections through a NAT to remain open long-term, it doesn't actually help with establishing an initial connection if both sides are behind a NAT or closed firewall.

Tailscale handles this, and can establish a direct connection between two machines without either of them needing an open port listening for new connections.

There's an article on their website that explains how they do it: https://tailscale.com/blog/how-nat-traversal-works