I can only recommend giving headscale a try. It's free, works extremely well, and can be used with the official Tailscale clients. Was super easy to set up.
A) easy access my other, older machines from my phone or work laptop to:
- self-host a Coolify server (a "vercel-lite" control panel)
- remote connect to my older laptop to run tests/longer coding tasks for work (e.g. large browser test suites, sandboxed claude running in bg to answer longer code questions, or build fire and forget spikes/experiments)
- control my home cinema remotely (remote+ app bc it's easy and Remote Desktop).
- use w. Mullvad VPN as an exit note (Tailscale has a really easy UI for it nowadays)
B) use it like ngrok to expose my dev servers to the internet (e.g. when sharing a quick demo/pairing with a coworker)
C) cheap NAS - I the old mac is connected to an external HD (the HD itself is archived to Hetzner)
I haven't (yet) tested it as an alternative to Hamachi (is it still a thing?) but I'm planing a LAN party with my brothers who live across the continent.
Like you, I also didn't know what the fuss was about, and I'm generally cautious not to get sidetracked.
Wireguard, talescale, netbird, etc. are layer 3.
It has a pretty good ACL functionality, you can configure which hosts with certain tag can access certain routes.
hs.mygreatplace.com
Now, when I install Tailscale client on any device (phones, tablets, Linux machines, proxmox nodes, etc.), I simply say: don't use the tailscale network for this, please route this over my own network, so you point it to hs.mygreatplace.com as a connectivity server, which is compatible to Tailscale, and that's it. It's officially supported by Tailscale, so that's great and makes it all work.
Then, when pairing for the first time, you'll get a link/code, click it and/or enter it on the hub basically (hs.mygreatplace.com) and it's paired.
That connection is up and will stay up now. So while that new device may be behind a firewall, I can always connect to it. You open Tailscale and see all your paired devices. They basically now get an additional internal ip (100.0.0.1, etc.) and you use that to ssh or connect to it.
I have a beefy Proxmox machine, and used to route many of these services out to the public internet through port mapping, but now I just leave them cut off entirely and only surface them inside of my private network. When connecting to these nodes (from iPhone, Laptops, etc.), there's zero configuration once it is set up, it auto-routes correctly and just acts like those nodes are on the internet, it's a dream.
It also automatically adds the node as a subdomain, so if you pair a proxmox node that runs grafana, and maybe has a hostname "grafana", it will show up and be always reachable as: grafana.hs.mygreatplace.com
It doesn't get much easier than that.
All that said, I HIGHLY recommend Tailscale for anyone who hasn't done much with private networking, just to try out first, and get used to it. Their free tier is very generous and I think they've got a fantastic next-to-zero-config product, truly wonderful. However, my concern was to be trapped with a $160m dollar VC-funded (US-based) company, when the inevitable rug gets pulled (as it always does, and as anyone should come to accept, if you've been on the internet for a minute).
So I was looking for alternatives, and headscale immediately worked out. Of course, Tailscale ever killing their client's ability to use your own infra will lead to a similar end result (dead end), but I am sure those things can eventually be sorted out by open source attempts and clients (which headscale has, I just haven't tried them out yet, https://headscale.net/0.25.0/about/clients/).
I had a Wireguard network before (which this essentially also is, but in a much nicer packaging), but always ran into config problems with the shared profiles and IPs and so forth, so this was just a simpler step.
Worst case, it all goes back to Wireguard.
I ssh through the tailnet network without worrying about remembering ips because of how their magicdns works
I have deployed some admin dashboards and it simplifies the security a lot because I don't have to worry about them being exposed to the internet, I can directly connect to them using http://my-vps:port on any device connected to the tailnet
I sometimes also use my vps as an exit node whenever I need a vpn
I know this might sound like a commercial but it is not, it's one of those pieces of tech that has really changed how I work since I discovered it and I can't do other thing than recommend it
That said, their free tier is more than enough for me, and if they haven't one I probably wouldn't pay for this and just find an open source alternative
I haven't checked headscale in depth but seems promising, will give it a try
But this is where netbird beats tailscale: coordinator server open sourced out/self hosted out the gate.
Headscale is currently maintained by a few tailscale employees on their spare time. Currently, Tailscale allows this to happen but clearly there’s some internal management of what gets downstreamed to headscale.
What I don’t like about headscale is that you can only host a single coordinator server as well. If I need to do maintenance on the server, it means an impact to the tailnet. It’s rare but annoying.
Any p2p connections should keep working for some time even if the coordinator goes down... right?
> Scaling / How many clients does Headscale support? > It depends. As often stated, Headscale is not enterprise software and our focus is homelabbers and self-hosters. Of course, we do not prevent people from using it in a commercial/professional setting and often get questions about scaling. > Please note that when Headscale is developed, performance is not part of the consideration as the main audience is considered to be users with a modest amount of devices. We focus on correctness and feature parity with Tailscale SaaS over time. [...] > Headscale calculates a map of all nodes that need to talk to each other, creating this "world map" requires a lot of CPU time. When an event that requires changes to this map happens, the whole "world" is recalculated, and a new "world map" is created for every node in the network. [...] > Headscale will start to struggle when [there are] e.g. many nodes with frequent changes will cause the resource usage to remain constantly high. In the worst case scenario, the queue of nodes waiting for their map will grow to a point where Headscale never will be able to catch up, and nodes will never learn about the current state of the world.
I find that quite interesting and it is one of the reasons I've not really considered trying out Headscale myself.
I mean this is a great advertisement in and of itself. Something being considered "enterprise software" means it will have 90% more features than needed, the code will be a combination of dozens of different mid-level devs new perfect abstractions and will only test code paths through all those features that the original enterprise valued. I.E. it is great if you work in an enterprise as it will generate a lot of work with an easy scapegoat.
On a different note; the HN obsession with SQLite these days is getting a bit tiresome.
I started with a docker container that connected to both the VPN provider and tailscale. Now OPNSense is handing a few connections to the VPN provider at a couple locations around the world, and enforcing external traffic to be routed to the VPN connections via VLAN tags (untagged has direct internet access).
Using the VPN provider can either be adding a VLAN tag to a machine/container or connecting to a "vpn-{location}" tailscale exit node.
That said, I've been using headscale on 220 devices for ~3.5 years now and it's been quite reliable.
So instead of opening a port on my firewall for WireGuard, I must have these ports public exposed:
* tcp/80
* tcp/443
* udp/3478
* tcp/50443
I don't know about you but that seems the most insane approach. Even if HTTP-01 challenge is not used, you are still exposing 3 ports instead of 1 random-high port like 55555 for example.
Yeah yeah, you can use rever-proxy but still, you are exposing way more ports and services to the internet than just one port for WireGuard itself.
- TCP/80 is only required to answer let’s encrypt challenges for certificate issuance
- UDP is only required to enable DERP.
These are both optional.
It’s not surprising that there are additional ports required on top of Wireguard. 443 is likely for key distribution and management. If you don’t want PKI then you don’t need headscale; you can always distribute the keys yourself and just run plain wireguard
It makes more sense to me, WireGuard + SPA (fkwnop aka replacement of port knocking that requires pre-shared key to even talk with, only that IP can access to it (IP Table), any scan tool seems it as closed)
Headscale/Tailscale only has value if you are behind a CGNAT, otherwise, it just adds extra management and complexities.
UDP/3478 is STUN for the embedded DERP. I recommend hosting a distinct DERP server, thus decoupling the control and data planes. DERPer is open source from Tailscale.
50443 is for GRPC. I'd not expose that, even if it is protected by authentication (and tested).