I recommend it the NetBird team is transparent and easy to reach. I switched from Tailscale a while ago (2y), went fully self-hosted, and upgrades across versions have been smooth, which tells me they care about the self-hosted, not just their cloud offering.
We tried netbird but could not get the client to register to a self hosted server. It ignored the setting or failed.
Good chance it was user error on our part.
Most of their documentation is very unclear about what is a cloud offering feature and what is possible using self-hosting. There are features not available on the community edition and you have to be very careful reading their doc.
Just putting it out there so people do not think it's an easy solution. It will require appropriate planning.
I do think its a more promising solution than headscale if you want to self host as it is a complete package, unlike tailscale where you need to modify registry keys to change the cloud URL and headscale is a simplified, non-multi-tenant signaler.
You can also use profiles and set management URL in the settings through the UI. You can even switch between self hosted and cloud versions: https://docs.netbird.io/client/profiles
We also had a bunch of problems. The DNS resolution didn't work, and support was unable to figure out the reason.
A coworker reported domain access breaking when he went to office 1, but fixed itself when he went to office 2.
For a while, when you logged in with the wrong account, it was near impossible to replace it. This on is fixed now, but the entire thing still feels very much like paying for beta software.
Tailscale is the only non-self-hosted part of my setup now and this has bugged me since. I use a custom Nameserver rule to point all my subdomains to a Caddy container sitting on my Tailnet. Caddy handles the SSL and routes everything to the right containers. I skipped Tailscale Funnel on purpose; since these are just family services, I’d rather keep them locked behind the VPN than open them up to the web.
This project looks promising as a replacement for my current setup and for its digital sovereignity of self hosting the server. I'm looking to manage several embedded devices remotely via Tailscale, but I've hit a major roadblock: the 90-day maximum expiration for Auth Keys. Constantly renewing these tokens is a significant maintenance burden, so I'm searching for a more permanent, 'set-and-forget' solution for my remote hardware.
can you please tell me how to disable expiration time? I see auth keys have an Expiration which says it "Must be between 1 and 90 days."
I do use a custom domain name as well with a Nameservers rule to have all my services reachable as subdomains of my custom domain.
There is some confusion here because while you can disable node key expiration, you can’t disable auth key expiration. But that’s less of a problem than it seems - auth keys are only useful for adding new nodes, so long expiry times are probably not necessary outside of some specific use-cases.
Edit: in fact from your original post it sounds like you’re trying to avoid re-issuing auth keys to embedded devices. You don’t need to do this; auth keys should ideally be single-use and are only required to add the node to the network. Once the device is registered, it does not need them any more - there is a per-device key. You can then choose to disable key expiration for that device.
I want my CI containers created per branch/PR to have their own Tailscale domain, so logging them in is useful via non-expiring key. Only good option I've seen previously is to notify every 90 days when key expires.
The best way to do that is using an OAuth client. These don't expire, and grant scoped access to the Tailscale API. You use this to generate access keys for the devices that need to authenticate to the network.
We use this for debugging access to CI builds, among other things – when a particular build parameter is set, then the CI build will use an OAuth key to request an ephemeral, single-use access key from the Tailscale API, then use that to create a node that engineers can SSH into.
Use tag-based node authentication. Login as a user and then switch the device to use a tag. I just recently did that and retained the usual 6 months expiry. I can also disable key expiry completely.
When managing your infrastructure as code, it’s quite common to deploy new instances for upgrades etc. Having these keys expire after 3 months is a big pain. Eg doing a routine update by rebuilding an AMI.
I don’t understand how they can have such a strategy, and then not having any decent way to programmatically allocate new keys.
This can all be automated using e.g. the Terraform Tailscale provider, which takes the OAuth id/secret and can then issue keys as needed for the infrastructure you are deploying.
Long-time ZeroTier user here. Recently switched to NetBird (self-hosted on a Hetzner VPS) and it’s been seamless so far. DNS functionality is excellent (something ZeroTier lacked), and the access-control model is very well designed. It’s easy to understand what’s going on and to grant one-off access when needed. Only real and very minor gripe is the Android app: I wish it were on F-Droid and a bit more robust, as it sometimes drops when roaming. Nevertheless, congratulations on a fabulous piece of software! I hope it keeps improving :)
As other have pointed out, Tailscale and Netbird are much more than wrappers around Wireguard. ZeroTier does not use Wireguard and they have their own lightweight tunnels, which in their recent multi-threaded implementations are more performant but not as fast as Wireguard in my testing.
I don't think there's a direct way to integrate any of them into existing mesh networks, but I could be wrong.
I had to use tailscale to bust through port forwarding on chained routers because, even with ports configured correctly, wireguard wasn't able to get through.
My use case was for remote access into a home-hosted Nextcloud instance, via an ISP supplied fibre router (IPv4, not CGNAT), then my own Gl iNet router, then to my Nextcloud instance.
Despite opening up port forwarding correctly, wireguard just couldn't get through that chain, whereas tailscale got through with no problems.
Downside of using tailscale is that it's messy to use at the same time as a VPN on your client device. Split tunnelling supposedly works, but I couldn't get it going.
They are not only a wrapper for Wireguard even though people keep saying that.
Each of the tools gives different benefits and yes, you can roll all of that on your own, but let's take Tailscale as an example: You have custom ACLs to secure your network on a client/user/device basis with tagging of devices. You have your own tailscale SSH connection, the possibility to create private-public tunnels (just like Cloudflare tunnels). The hole punching using DERP servers and native IPv6/IPv4 interoperability means it really connects any device on any network type to all other devices. And of course the management pane and GUI you talked about.
This is not supposed to be a marketing ploy for Tailscale, but saying "they are just a wrapper for Wireguard" is plain wrong.
But paid Tailscale is $5 a month right? So you gotta be paying more to self host and deal with all the problems yourself, not have derp servers all over the world, etc. Why?
Why do you assume OP paid $5 a month? You get Tailscale for free in many use-cases. Your argument that self-hosting is more expensive is still valid, but I don't get the 5$.
I already run a VPS for other things, this fits cleanly into that setup, NetBird’s been low-maintenance, and I don’t need global relays. That’s enough for me.
Also long time zerotier user here, I run a controller for our company. I'm starting to experience infrequent but annoying drops in connection, and DNS is a headache.
I switched from Zerotier to Tailscale last year and Tailscale is far more performant and stable but Zerotier works better with multicast, specifically multicast video. I even ran a Zerotier moon to help but it was still worse than Tailscale.
I've been working for a while on https://github.com/connet-dev/connet. It gives a different twist at the same problem - instead of an overlay network at L4 (wireguard, etc) or publicly accessible endpoint at L7 (like ngrok) it "projects" a remote endpoint locally (e.g. as if you are running the service on your computer). Of course "locally" can always be a VPS that has caddy in front to give you ngrok-like experience.
The reason connet exists is that nothing (at the time I started, including netbird, tailscale/headscale, frp, rathole, etc) gave the same easy to understand, FOSS, self-hosted, direct peer-to-peer way of remote access to your resources. I believe it does accomplish this and it is self-hosted. And while a cloud deployment at https://connet.dev exists, it is nothing more then repackaging the FOSS project with user/token management.
This is meant just for computers, right? A quick check of the readme showed that devices must run this or that commands, which seems difficult to do on an smartphone. I guess the ngrok-like setup would be the way to go for that case, given the increasing prevalence of phones and tablets as the single form of computing for lots of people
I've been thinking a lot about this case specifically. And you are right, phones are largely not supported right now - I've been researching how to make that happen. One case I've found that works for me currently is running connet via Termux - and I've made the necessary changes to support that.
Native iOS/Android clients, if possible, will probably be the next things I'll work on. At minimum they should enable you to run a "source" (e.g. a consumer of an exposed service), but ideally it will be the whole deal.
A neat idea, but projecting all of these services onto localhost is a bit of a security nightmare. Have you considered looking at what something like Twingate does? Using the CGNAT IP space for the projection allows you to give every individual service its own IP address, which helps quite a bit in terms of allowing you to isolate the services from e.g. malicious web pages.
I'll take a look at what twingate does for sure, thanks for pointing that out.
A few things that worth mentioning for connet's current state - you can technically bind to any local IP, not just loopback (or listen to them all). You also have the option of directly running a TLS/HTTPS destination (for mutual TLS directly to the service) or source (e.g. for mutual authentication between your local listener and the outside world). Another option is to build your own client and define how you want to source traffic - maybe its part of your app and there are no sockets or anything - you just connect and start talking.
(Shamless plug) I am also working on a similar FOSS, self-hosted project called Octelium https://github.com/octelium/octelium that you might find interesting if you are interested in this space. Octelium is, however, more of a generic/unified zero trust secure access platform that can operate as a remote access VPN, a ZTNA platform, API/AI/MCP gateway, a PaaS, an ngrok-alternative and a homelab infrastructure. It provides unified client-based as well as clientless access for both humans and workloads; dynamic identity-based secretless access (e.g. access to HTTP/gRPC/k8s upstreams without sharing API keys and access tokens, SSH without distributing passwords/private keys, postgres/MySQL databases without sharing passwords, etc.); dynamic L7-aware, identity-based access control ABAC via CEL and OPA as well as dynamic routing to upstreams via policy-as-code; native Passkey login/WebAuthn/TOTP MFA and support for OIDC/SAML IdPs, OpenTelemetry-native L7-aware visibility and auditing; clientless access via OAuth2 for workloads, WireGuard and QUIC tunneling with dual-stack and automatic private DNS, including in rootless mode; passwordless SSH'ing into containers and IoT without SSH servers; deploying and securing access to containers; declarative k8s-like management with horizontal scalability among other features. You can read more in the README if you're interested.
It took me too long to understand the difference between the two so I'll leave it here for others. Octelium operates on OSI Layer 7 and Tailscale operates on OSI Layer 3 and 4.
Well, yes, Octelium is technically a VPN from a layer-3 perspective since it uses WireGuard/QUIC tunneling, but the tunnel doesn't directly terminate to the destination like in VPNs but instead to an identity-aware proxy that does authentication and L7-aware authorization on a per-request basis with policy-as-code via CEL/OPA. From an architecture perspective, I assume it's closer to ZTNAs such as Cloudflare Access and Teleport than to traditional VPNs, even though it operates as one for the clien-based access mode. However, unlike VPNs, it does provide clientless/BeyondCorp access too as it's intended to operate as a more generic/unified access platform (e.g. API/AI/MCP gateway, ngrok-alternative, PaaS-like platform, etc.) rather than just a VPN.
Yes, every resource that needs to be protected is represented by a "Service" that's implemented as a L7-aware identity-aware proxy in the Octelium Cluster, which is a distributed system that's running on top of a k8s cluster. Users simply access the protected resource/upstream through the Cluster, namely the Service, from a data-plane perspective, and the Service/identity-aware proxy does authentication/authorization/routing/visibility on a per-request basis. This upstream could be an internal resource directly accessible by the Cluster, or remotely behind NAT, or simply publicly protected SaaS resource (e.g. API protected by an access token, SaaS database protected by a password, etc.). You can read more about how Octelium works here https://octelium.com/docs/octelium/latest/overview/how-octel...
I've been keeping my eye on this one, it's very interesting.
Feel free to ignore this, but, what's your long term plan here? I see you have Enterprise plans (especially that allow different licenses). From what I can tell you're the only contributor, but, I assume that if you accepted contributions there'd be a CLA?
Thank you, I haven't accepted any contributions so far primarily because of this reason but things might change in the future. As mentioned in the README and docs, Octelium is designed specifically for self-hosting so the commercial side of the project is simply confined to commercial AGPLv3-alternative licensing, support, and other very enterprise-y/customized features such as SCIM, SIEM to specific providers, etc...
Do you foresee this changing anytime soon? Would love to contribute but also I think community adoption and contribution would go along way in terms of businesses less worried about single points of failure.
It’s hard balance to strike for sure. And it’s getting weirder by the day with agents.
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.
Could you give a brief description of your use case? I'm looking at all the tailscale buzzwords on their site, but am not really understanding what I would use this for in my home setup
Not sure about the parent, but here's what I use it for:
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.
I run it on all my vps and allow me to close every port but 80 and 443, even port 22 is closed
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
I have some servers sending their telegraf data to a server in my home using the tailnet instead of opening a port on my firewall for that, to name one use case.
It has a pretty good ACL functionality, you can configure which hosts with certain tag can access certain routes.
yeah the amount of nodes I had on the public internet, when all I really needed was some internal connectivity (exactly like you have here, a machine sending logs to an internal-only loki instance, and then a grafana node that is also only internally relevant and never needs to see the public internet), etc.
I have one VPS node that I use as a connector, where the headscale app is installed. I have this on a domain (for convenience), so think something like:
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.
well the OP talks about headscale server (self-host) which will run whereever your server that you install it onto will be. You just use the tailscale clients.
Headscale is good. We're using to manage a two isolated networks of about 400 devices each. It just works. It's in China so official Tailscale DERPs do not work, but enabling built-in DERP was very easy.
headscale is an awesome project. And I love tailscale as a product.
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.
> 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?
Headscale mostly works pretty well but its pretty finicky to get set up in a way where the tailscale clients on linux and android aren't always complaining with warnings or having route or DNS issues. I'm considering investigating one of these non commericial solutions where the entire stack was built to work together.
Apparently they've deprecated Postgres support and now only recommend sqlite as the storage backend. I have nothing against sqlite but to me this looks like Tailscale actively signaling what they think the expected use of headscale is.
> 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.
Why? Makes perfect sense to me. Designing a product with a specific use case in mind is good. When you've got the limited resources of am open source volunteer project, trying to solve every problem is a recipe for burnout. If it can even be done.
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.
I dont understand what these two have to do with anything? The db-use is almost trivial, and SQLite can be embedded. Why would we want wasted effort and configuration complexity on supporting postgres?
With that kind of logic you wouldn't need headscale and would just ask your favorite LLM to write a similar tool for your with your own requirements and nothing else.
No, not really necessary to extrapolate the logic any further. You have deemed a very specific and focused task as "wasted effort." So the logic leads to putting in the effort you do not find "wasteful" and outsource the remainder to the LLM do this very specific thing.
TIL! My problem with them requiring sqlite was that I assumed it would make a high availability setup either hard or impossible. Maybe that's not true, but definitely off the beaten path for headscale.
Yeah, Headscale people don't hide that it's a toy. I didn't get a homelab full of datacentre-grade equipment because I want to use toy, nonscaling solutions with vastly incomplete feature sets, but for the exact opposite reason.
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.
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
>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.
Well, it also lets you federate access and manages the keys for you. But yeah, if it’s a personal setup and you have good key rotation hygiene, I agree with you: it doesn’t add much value on top of wireguard. I’ll hazard a guess that you can just run your own DERP relay too for the CGNAT case.
80/443 is all that's necessary for Headscale as a control server.
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).
I'd say no, but it really depends on what your use is. The biggest barrier is that it doesn't have a HA story that I'm aware of, but you might be able to get one by carefully replicating the sqlite and using something like pacemaker to fail over and fail back.
That said, I've been using headscale on 220 devices for ~3.5 years now and it's been quite reliable.
yeah looks like someone is either a hyper tailscale fan or had extremely bad experience with it, I also run several dozens of machines (and tablets and phones) on it. never had a single moment of downtime since I started.
I like Netbird, its a better VPN, but its not zero trust networking. Zero Trust requires identity to create connectivity itself—per service, per session—rather than granting network reachability and constraining it with routes and rules. I have had this conversation on Reddit many times... curious if anyone agrees/disagrees.
Short answer: no, authenticating to start a VPN doesn’t make it Zero Trust.
Once you authenticate to a VPN, you’re granted network attachment. From that point on, the network is effectively saying “I trust you enough to route packets,” and enforcement shifts to IPs, subnets, and firewall rules. That’s still network-level trust, even if the login was strong.
Zero Trust (architecturally; check out NIST 800-207) changes what identity does:
- Identity doesn’t just gate entry
- Identity + policy decide whether a path exists at all, per service, per session
- If you’re not authorized for a service, there is literally no route, IP, or port to talk to
On your last point: it’s not “only application-layer,” but it’s also not traditional L3/4 networking. It’s an overlay where identity is bound into connection establishment itself (mTLS/E2EE, service addressing, no inbound listeners), so the network never becomes a trust plane in the first place.
That’s the difference between “authenticate, then connect to a network” and “authenticate to create connectivity.”
For a reference, check out OpenZiti, thats a project I work on - https://openziti.io/
it should have support for signing of the configuration that is sent out to all nodes by a key the administrator controls, and which is then whitelisted on all nodes by oneself. That way the central node is just a simple data provider/helper.
right now you are screwed if someone compromises your coordinator
NetBird doesn't require network reachability (it used relays for NAT traversal) and creates the keys itself. It doesn't do any routing. It uses wireguard underneath.
For someone who want to setup a private network between host/devices, I feel the dilemma is always:
1. Trust a third party like Tailscale by giving them the key to your kingdom, but everything is incredibly easy and secure.
2. Self-host but need at least one host with a fixed IP address and an open port on the Internet. What requires a set of security skills and constant monitoring. That includes headscale, selhosted netbird, zerotier or a private yggdrasil mesh.
You can conceal that open port with some form of port knocking. Though this does reinforce your "easy" point.
Also, if it's an UDP port, then using a protocol that expects first client packet to be pre-authenticated and not emitting any response otherwise gets you pretty damn close to having this port closed.
I looked into it but it seems that port knocking and Single Packet AuthZ literally open the firewall and expose the port when used.
Meaning it is great to reveal the SSH port when needed, do your business quickly and close it back when you are done. But my guess is those overlay networks need to port available all the time, so...
When I look at these zero trust solutions need 80/443 for what seems some type of bootstrapping
Better it happens using the same approach wireguard takes (udp/stateless). Though I'm not sure if there's more than just bootstrap taking place, maybe constant routing updates etc
Why do you think thats against the principles of zero trust? Wireguard is a wire transport, it has no control plane... I think what you are alluding to is the centralised control plane which makes it possible to operate at scale (and much more).
You could use a solution that allows you to have E2E with private sovereign keys on the endpoint, as well as bring your own IdP/PKI, so the provider does not have your keys. Would that be good enough?
Nebula just had a major release that added IPv6 support for overlay networks. Hardly maintenance mode.
The main company working on it now seems to be adding all the fancy easy-to-use features as a layer on top of Nebula that they are selling. I personally appreciate getting to use the simple core of Nebula as open source. It seems very Unix-y to me: a simple tool that does one thing and does it well.
Fair, I was being loose with my language. What I should have said is that it does not come fully featured open source, that you need to do a certain amount of rolling your own.
Right, but if certificates are a fundamental part of your design, you should include the functional mechanisms to manage them imho (i.e., key distribution, auth/login). The developers created it, but they keep it in the commercial product. Other overlays which use PKI include those functions in the FOSS.
Yes, but when you connect your phone to a Nebula network, and go to http://media-server in your browser, the DNS won't resolve it to your desired node, because the phone client (same on desktop) didn't update DNS of the phone, so you'll have to use node's IP address.
That's what I've read (when evaluating Nebula), at least.
It doesn't automatically update, that's true. But I think the typical way to deal with this is to have a nebula subdomain. www.nebula.example.com instead of www.example.com.
When your nodes are not very numerous, and their IPs are statically assigned, you can just have them in a hosts file, or even served by your normal name server if you're using a split-horizon configuration.
It is the easiest to setup and understand really. There are no users, just hosts and their keys.
What it doesn't offer is a gui or tool to handle copying/installing/revocating keys so you trade super easy setup for a handful of nodes to management overhead if you are scaling up and down regularly.
Going to mention my own project which aims to be 100% open source, free, and relies almost only on public infrastructure: https://github.com/robertsdotpm/p2pd
Basically, I'm building a framework for building NAT traversal plugins. Software like ngrok and P2P VPNs can then be built on top of it. Examples of plugins for the library include direct connect, reverse connect (connect back to you), TCP hole punching, and UPnP-based port forwarding.
The underlying network stack for the project was also built from scratch to better support IPv6 and multiple interfaces. This allows plugins to fully utilise the underlying network paths and interfaces on the machine. This took considerable time because most software simply uses the default interface.
I'm still in the middle of building the software so its not yet functional. But if anyone is interested throw me a star or an email at matthew@roberts.pm.
By the way I forgot to add: if anyone needs a list of public STUN, TURN, MQTT, or NTP servers I wrote a monitor for them last year and added a bunch of servers. This is basically the infrastructure I use for my P2P library. The public API is here: http://ovh1.p2pd.net:8000/servers or if you want to host it: https://github.com/robertsdotpm/dogdorm
Having it in F-droid, vetted by their policies is kind of my benchmark for "software that is guaranteed to be not crapware."
That being said I'm rooting for the devs, having an alternative for tailscale+headscale would be nice, because as it stands it's kind of dependant on the goodwill of a for profit company (finite).
I recently brought my first app to F-Droid. It was not friction free, but I was able to do it within a few weeks. Seems they put not much effort into this, e.g. the basic check marks are not even checked...
I tried migrating our organization from Twingate to self-hosted Netbird for cost savings but couldn't get it working reliably for 10-15% of users. The client failed intermittently with no clear pattern to troubleshoot. It became very frustrating for our end users. My advice: if you're considering self-hosted Netbird, set clear expectations that it's best-effort QoS, not enterprise-grade reliability. There's no such thing as a cheap VPN.
Would you mind sharing more about the issue? We have enterprises running NetBird with thousands of users with near zero issues. Apparently it is usually other way around - people migrating from Twingate to NetBird because of the former solution instability. Well, that is from our experience.
I suggest trying NetBird cloud to eliminate a potential misconfiguration of the self-hosted instance.
DNS resolution failures occurred inconsistently—sometimes due to browser caching when accessing web resources, but often for no apparent reason. For some users, restarting or reconnecting Netbird resolved it; for others, it didn't. The fact it worked flawlessly for some users while barely functioning for others suggests client-side issues. We also saw sporadic failures in cron jobs (like DB exporters) that never happened with Twingate. We followed the Helm chart configuration exactly and properly configured the Network Load Balancer with appropriate timeout settings.
I have been using Netbird for my small company of 10 people for about 2 years. Users on slow connections complained that they could not stay connected with services reliably. I could not reproduce the problem as I mostly connected from very fast connections. I thought that maybe the users or their ISPs were to blame. And then one time I was using the wifi on a plane. It was a slow connection and I was connected to an RDP server. I could not stay connected. I also has Cloudflare VPN connected to the same server. It worked really well over the same connection. I went back ad forth many times as I had trouble believing how bad the Netbird connection was. Long story short, we are now completely switching over to Cloudflare VPN. It is free for first 50 users and is very very reliable, in our experience.
Check out OpenZiti. Its open source, runs at prodution scale, and recently someone who used to work at Twingate said OpenZiti is many times more powerful than TG.
OpenZiti is promising but their desktop and mobile clients are very incomplete.
The feature set varies greatly between platforms.
If you are supporting a single platform (example desktop windows) it could work. Even better if you have the resources to write your own clients using the SDK, like it's meant to be.
From memory: oAuth login flow
(browser based) was only supported on the windows client. For a Zero trust solution, having the only auth truly supported be a permanent JWT/Cert on the machine is doing device authentication, not user authentication, thus completely failing your primary objective.
UX was overall atrocious. Our users could not comprehend it at all. It was deemed that a custom client was required to be made.
The SDK first approach was an overall major plus point, allowing for a full customization to a specific use case.
Don't get me wrong we were overall impressed with the technology and the architecture choices. It's not a finished product, but something that does all the infra and you just need to apply the final veneer on top.
Ahh, I see, thanks for clarifying. That was correct, now any OIDC-compatible identity provider (Auth0, Okta, Azure/Microsoft Entra, Google, Keycloak, etc.) is supported on all the tunnelers to my knowledge.
Lots of work continues to go into the UX, but I would note that we focus most of the UI/UX work into NetFoundry, our commercial product.
The problems we had is users could not reliably tell when they were connected/disconnected, how to initiate the login flow, get network status (why is that service not working, but this other one is?), tell to which router they were connected, etc etc. I know these are big asks, and I suspect a lot of these troubleshooting and status info are probably available in the commercial offering.
That being said I think OpenZiti/NetFoundry is in a different class entirely and any lurkers here should consider it for their use. It's not really the same thing as NetBird or Tailscale.
Yeah, definitely more on the commercial side of the product.
And agreed, I like NetBird/Tailscale/Wireguard, but they are better VPNs, not identity-first, zero trust overlays as OpenZiti/NetFoundry is. That's why companies like Siemens have adopted it and many more will.
Please be aware that when you use tailscale funnel you announce to the whole world that your service exists (through certificate transparency), and you will get scanned immediately. If you don't believe me just put up a simple http server and watch the scanning request come in within seconds of running `tailscale funnel`.
Do not expose anything without authentication.
And absolutely do not expose a folder with something like `python -m http.server -b 0.0.0.0 8080` if you have .git in it, someone will help themselves to it immediately.
If you are aware of this, funnel works fine and is not insecure.
Tailscale IMHO failing in educating people about this danger. They do mention in on the docs, but I think it should be a big red warning when you start it, because people clearly does not realise this.
I took a quick look a while ago and watching just part of the CT firehose, I found 35 .git folders in 30 minutes.
No idea if there was anything sensitive I just did a HEAD check against `.git/index` if I recall.
Out of curiosity, why? I use TS for all my homelab bits (including my HA instance), but connect to TS before opening the HA app. Is it just a case of making it easier/ possible to connect if you’re on another VPN? Are you not concerned with having something from your local network open to the internet?
After a decade with KeePass, I’ve finally moved to Vaultwarden. I’ll admit, self-hosting such a critical service still feels a bit scary, but the seamless syncing across all my devices is a huge upgrade. To balance the risk, I keep it tucked safely behind Tailscale for that extra peace of mind.
Do you have anything that’ll trigger a notification if there’s suspicious traffic on your local network? I may be overly paranoid about exposing things on my local network to the internet.
Besides the use cases listed, we see this as an opportunity for homelabers and organizations to add authentication with access control to already exposed services.
We are developing a similar feature and is scheduled to be available really soon. We've discussed some details in our public slack. Any feedback there will be helpful.
I was previously using headscale and was finding it a bit finicky. Recently switched to self hosted netbird and its been great so far. However, if the Netbird teams sees this, please implement a built-in updater for the client apps! needing to download and install the package again is a bit annoying
I wish they'd chill on the release schedule and keep it to once a week or less. I keep it maintained in my Gentoo overlay but oftentimes when I go to bump it, they push another release. Since this submission was posted they've had yet another new release.
I've looked without success for external audit reports of either Tailscale and Netbird, like Mullvad gets. While I don't approve of the sort of auditor box-ticking we get at work, it would be reassuring to see a report from a proper security consultancy.
Netbird has supposedly done a penetration test, but it is only supplied upon request [0]. I haven't bothered trying to get my hands on it since I don't use their product. I don't agree with gatekeeping the results instead of making them public.
NetBird should also consider publishing an SBOM, similar to what Defguard does.[1].
Oh, I hadn't found that. Yes, it seems strange not to publicize something like that to give users confidence (assuming the audit/pentest isn't damning). It doesn't have to have been perfect initially, as long as appropriate fixes were made.
I can't tell if Netbird provides this feature but looking at their access control feature it doesn't seem to.
I just want a roaming access Wireguard terminating endpoint to restrict access to a user to initial subnets, and open / allow routing to further subnets based on multi factor authentication. That way a user can connect and only have access to say a wiki and internal chat, but then escalate access by MFA to access resources on other subnets that have stuff like internal gitlab and whatever other critical resources exist.
We just evaluated this the other day and we were pretty impressed by it. We were looking for something we could self host for wireguard config but tbh we might just pay for the managed solution.
Has anybody looked at whether Tailscale is subject to the US CLOUD Act? If so I can imagine we might be moving towards an open source solution like this in future.
Tailscales founders are Canadian, principled, and are very sensitive to Canadian needs. I very much trust Avery and team to do what’s necessary to keep US hands off the data.
edit: someone pointed out they’ve signed new users on to a US co. 15 months ago. I made the statement without knowing this. they aren’t as capable as I originally claimed.
According to their ToS all customer accounts registered on or after September 3, 2024 are signed on to a US company, so no they're not doing what's necessary to keep US hands off the data.
I've head Netbird running for the last few months... In general it works quite well, but it would keep messing with my dns-resolving, and I couldn't find the setting to stop it inserting itself into my resolv.conf.
During the last few weeks I've removed netbird from all my systems (about 12), mostly because of issues on laptops where resolving or networking would break after they moved to a different network/location.
Just for future reference, you can disable DNS management for specific groups [0].
You can find the option under "DNS > DNS Settings > Disable DNS management for these groups". Netbird will stop modifying the resolv.conf on those groups.
Can Netbird run the DNS resolver (so it can be used for the internal domain ONLY by systemd-resolved) but not alter the host's DNS settings?
It looks to me like the setting that tells Netbird to leave the system DNS alone is arbitrarily tied to the setting that causes it to run a resolver at all.
Because I don't feel confident. I'm super green at VPN's and this kind of networks. I don't want to give the wrong advice.
I'm editing what I can, but you don't want to take my advice, it would be better if someone who knows does it.
The fact that I'm into home lab, doesn't mean I know specifically how to do this. And I'm just saying, when I go to the wiki, to pick up on one of the options, they are missing.
I don't know why the hostility for asking to add some docs
If you're a homelab NixOS user, isn't it on you to try to answer these questions? A home lab is for learning, and if you don't want to do that, what's the point?
Could be intentional:
German privacy advocates really like that the limited ipv4 pool forces reusing IPs and prevents accidental imprinting a practically static address on a device.
> The VM must be publicly accessible on TCP ports 80 and 443, and UDP port 3478.
> A public domain name that resolves to the VM’s public IP address.
Since it already uses DNS it's disappointing that it hardcodes ports instead of using SRV records. IMO anything that can use SRV records should. It makes for a more robust internet.
Can't do IPv6 internally or externally? Internally there should be zero need for ~infinite addresses. Externally though I certainly hope all software is capable of operating via IPv6 at this point because otherwise it will only be increasingly broken.
Can't do it externally, kinda. Last year I succeeded in joining a device reachable only through IPv6 to a Netbird network, but their service would fail when I tried to configure IPv6 nameservers for it; the web UI did accept them fine though, they just didn't work. A shame, since I was otherwise fine with IPv4-only for the Netbird network.
I have tried multiple different solutions of so called "zero trust networking". My personal favourite one is Netbird but.. it lacks one feature: switching between multiple setups (networks). I am helping to maintain some startups and it would be just nice to quickly change (or even better: have access to multiple at once!) networks.
> it would be just nice to quickly change (or even better: have access to multiple at once!) networks.
Accessing multiple corporate networks simultaneously from the same endpoint violates all sorts of access policies. If it doesn’t, the access policy is lacking. Even for startups.
And no, unless you build it and enforce it from the start, no one ever succeeds in bolting on a reasonably security posture after implementing all their other processes no one will dare touch.
I replaced Teleport by a bunch of various tools, and I had to chose between tailscale/headscale and netbird for the network connectivity. I’m pleased with netbird so far.
I had some weird bugs on a few old servers during the transition, and the support was helpful even though I am a small customer. We eventually switched to user space wireguard on those servers.
Marginally relevant as I am looking into Netbird and Headscale: Anybody can recommand a europe-based VPS hosting provider that gives you an IPv4 range (4-5 IPs) that I can route over headscale?
I'm really missing something like Cisco DMVPN. A VPN mesh between different routers where all routers have a connection to each other, so that all traffic doesn't have to pass through the hub. And that runs on a router, because all these solutions only run on a regular computer with a complete OS.
What is the issue with one Wireguard port open? You vpn to home LAN and everything is there.
The issue with these VPN companies is that they log data, you have to run an agent running as root, reliance on several other companies too like IdP, etc. Very large attack surface.
If your devices are in one network like at home, you have all those things with Wireguard too.
Devices in home LAN all talk to each other, so you have a mesh network.
You need keys for your laptop, phone and remote devices only.
Most nodes are in LAN and don’t need to even run VPN.
With plain Wireguard, you open a single port in a single device. With mesh VPNs you open tons of ports: several ports in coordination, STUN and relay servers, also every device runs a vpn server listening to a port.
You VPN to home and use your home DNS. Your enter ACL rules and DNS server in your router.
I use a mesh VPN but I’m thinking of switching back to Wireguard, my older setup.
I tried installing it and it was a pain, if you don’t use the very very default scripts.
Also their scripts regenerate secrets and the setup is weird in general (you need a complicated rp configuration and scripts to generate the config files)
Most of the self-hosted zero trust solutions require opening 80/443. It would be nice if they could adopt Wireguards approach of using UDP only, and only responding if the request is valid.
Maybe it's possible without modification to Netbird to setup a staging network.
Always my problem with Tailscale and similar solutions is that I already run VPNs in my personal devices and especially with android devices, I need to switch between two VPNs, which I find a friction that I do not want. Does anybody know a solution to this?
Tailscale has some integration with Mullvad. If you have a Mullvad subscription you can use their servers as exit nodes without dropping your Tailscale connection: https://tailscale.com/kb/1258/mullvad-exit-nodes
Outside of the particular combination of Mullvad and Tailscale I don't think there is any other way apart from switching between the two.
Maybe I don't understand, but the tailscale Linux clients definitely supports multiple accounts. I use that to reach multiple headscale networks and a tailscale one. No issues for me using it this way.
I'm aware of how old Tinc is, but I've yet to find anything compelling enough to get me to switch. Tinc is a little annoying to set up, but once it's going I literally forget about it.
All these higher level VPN/tunnel solutions are so popular but functionally I’ve only ever wanted layer 2 VPN. Inside the tunnel, I want the ability to reason about a remote network as if it’s local, not on a per-host basis.
I'm currently comparing it with pangolin and headscale for my small scale company infrastructure access. Been running headscale for my own setup for a while but maybe netbird or pangolin might be better for real production.
Pangolin recently added desktop clients for win/mac/linux[0] and the Private Resource feature (similar to Netbird's Network Routes/DNS), so it's starting to overlap with Netbird more and more.
That said, it seems focused on client-to-site (newt) connections, and I don't see support for client-to-client connections like Netbird’s SSH access. Also, their Private Resources don't seem to support TLS termination yet. (Correct me if I’m wrong!)
In my case, I have a k3s cluster running on Netbird with a Traefik ingress for TLS termination inside my home network. Thanks to netbird's P2P nature, traffic stays entirely local as long as I'm on my home WiFi. (I suppose one could achieve the same with a Netbird + Caddy + DNS-01 setup, too.)
I am in the same position but currently using Tailscale and realize how important and critical it has become for my whole family infrastructure. A self-hosted solution which allowed me to use Nameservers and TLS termination as I currently do would be awesome.
Missing some technical bits to be a true contender for me but I bet they are getting there. That said I've seen so many shadcn based scam sites that my brain starts associating shadcn with scams.
In general I would keep an eye on the path CF is following with warp: which is great, but since they are so big and in fast evolution, it is a bit of a mess (their doc is outdated and changes too frequently) not to count (literally) their support (free version, and our company's opinion only, of course) since on warp it is totally useless.
Netbird's flexibility with IdPs is really nice. I recently switched mine to Pocket ID. Overall, it's perfectly sufficient and lightweight for homelab use.
You’re from the dev team, right? Thanks for the amazing OSS!
Regarding the containers, AFAIK it's 5 for the core setup (dashboard/signal/management/relay/coturn) plus Traefik in my case. It feels like a bit much, but the services are almost stateless and not resource intensive even on my little VPS. The setup script (bash + envsubst) is so straightforward and thanks to good documentation, I’ve never found the setup confusing. (I use Renovate to keep things updated, but I’d love to know if there's a recommended update path.)
A couple of minor things I noticed: 1. the dashboard image isn't on ghcr.io. 2. the generated compose.yaml contains hardcoded values. It could be even better if it referenced values from a .env file instead.
By the way, are there any ways to support NetBird other than GitHub Sponsors?
I immediately looked at this and thought it was a tailscale clone.
I looked further into it and it’s essentially the same.
Implementation over ease of use of wireguard setup. Peer to peer modeling. Mesh networking. "Zero trust".
However, what I find interesting is netbird has open sourced their _coordinator server_. This allows for self hosting to be end to end.
yes with tailscale there exists "headscale", but it’s clearly a side project that few people within the tailscale company maintain on spare time.
One of the fears i have with headscale is a sudden change in leadership at tailscale, then the support from tailscale dies. Significant divergence occurs between headscale coordinator server and clients. Enshittification occurs and now forcing those smaller use cases onto their SaaS.
I love tailscale/headscale but will definitely give this a try.
Defguard is a *Secure by Design* solution, which means security is important (if not more) then functionality.
Lower latency or peer-to-peer communication does not automatically mean better security often it means a larger attack surface.
Defguard is also *the only solution that enforces MFA on every connection*, aligning with true Zero Trust principles never trust a user or device by default.
Why Peer-to-Peer Is Not Safer?
Peer-to-peer and mesh solutions can be faster because traffic flows directly between peers, but they almost always expose all components publicly and make it easier to hijack the network or inject unauthorized peers.
So what does Defguard’s Secure-by-Design Architecture mean?
1. Minimal gateway exposure
The Defguard gateway exposes only a WireGuard port. Compromising it would require a Linux kernel or WireGuard zero-day at that point, no solution is safe.
2. Isolated, stateless proxy
The only Internet-facing "application" component is a stateless proxy, deployed in a separate network segment. It has no access to the gateway, core, or internal resources.
3. Protected control plane
The core (control plane) runs strictly inside the intranet (local network that should not be exposed anywhere). No user data are exposed to the Internet or DMZ/other network segments. Also the MFA validation process is done in secure network segments (for example when doing MFA with Desktop + Mobile client biometry/faceID combined).
Why This Is Different from Mesh Solutions?
Most mesh VPN solutions expose their control and peer-discovery components publicly by design. This significantly increases the risk of compromise and peer injection.
So would you say then that it’s perfectly safe to send plaintext traffic between services over Defguard instead of also using mTLS?
I still wish that Defguard had an option where peers only used the public gateway to retrieve their p2p ACLs from the control plane but otherwise traffic flowed directly.
Defguard as of my knowledge is a traditional VPN with a central gateway. NetBird is an overlay network with a full mesh capabilities. Though you can set it up in a gateway-like style with NetBird Networks but without opening ports and with HA out of the box: https://docs.netbird.io/manage/networks
Tailscale is great and headscale is an important step to gain trust. However, headscale is useless without the clients, and Tailscale geoblock installing clients where they can. If the platform requires jailbreak for installing user-chosen software, as is the case with iOS, then it all becomes useless.
Open (preferably free software) clients without idiotic restrictions could be one of the main advantages for any competing solution. Does Netbird provide them?
I don't care why. They do nothing to circumvent this so they are not a reliable solution for those who have network participants using the restricted platforms.
There could be a million reasons, but not a technical one — "headscale client", for example, could exist in current hostile app stores, but there isn't one.
Your arbitrary, loosely-detailed complaints would apply to literally everyone, every app.
It's on f-droid, it's open source, you're being ridiculous. I'm not even sure you understand what you're asking for. The official, open source Tailscale client explicitly supports headscale servers.
It's the only app from the ones I use that my friends and relatives who already use iOS can't even install due to geoblocking.
If you don't see it as a problem means you're not affected and perhaps lack some empathy.
Yes, I understand the Apple ecosystem is a problem. But it's not an insurmountable one. Builds of Free Software exist on Apple Appstore and none of them exhibit this problem, unless they are tied to a commercial entity in the corresponding jurisdiction. The issue with Tailscale is that they use their open-source clients and headscale as means to gain user trust, but their solution is deficient due to everything mentioned above.
> I'm not even sure you understand what you're asking for.
I'm asking for a free software client to go with the headscale server that can be installed everywhere technically viable, without idiotic additional restrictions.
It's clear that it's you who don't really understand the crux of the issue (which you partially admitted by you "not even sure", but still), but it's somehow I who's ridiculous.
I guess I'll just say that I hope you share the blame with the appropriate parties whenever you are suffering through iOS entitlements and provisioning to publish or self-load it on your iPhone, since Netbird's iOS client is open source.
Though, maybe it's not doing business in the US, and maybe the app is not similarly geo-blocked.
Actually can you not just pull the app and then side-load it anyway? That's what I would do if I couldn't get Tailscale from the Play Store...
Maybe this comment helps shed light on who I think are real the cause of your ire. Frankly I strongly agree with Brad's comment on why they don't care to open source the iOS client like they do the Android one.
I'm not sure where you saw ire. The only direct negativity was aimed at restrictions themselves, which is the product of foreign policy of specific countries and Apple politics. I'm not angry at Tailscale, just disappointed and annoyed.
> Actually can you not just pull the app and then side-load it anyway? That's what I would do if I couldn't get Tailscale from the Play Store...
The issue is, even if it's possible (which I doubt, since the users in question are not in the EU), it's technically challenging and the whole point of using a VPN solution was connectivity, which, besides other things, facilitates me technically assisting others. Besides, where do I even get the iOS client to side-load?
The point of my initial post was to ask if Netbird suffers from the same deficiencies as Tailscale (which are a fact). The question still stands, BTW.
It's interesting how you seem to dance around understanding exactly why Tailscale is geo-blocked and then also try to act "curious" like Netbird will be different. And somehow, you can't or won't just go check for yourself if the app is available in your region. Hm.
And it's interesting how you miss that it's not me I was talking of, assume I own an iOS device to check anything and am in the same region where the Tailscale client is geoblocked. Not to mention how you mixed Google Play and Apple App store during the discussion. Hm.
Agreed WireGuard itself doesn’t require microsegmentation, as it’s just a tunnel.
The point is the mesh products built on it tend to add identity + ACLs, which makes least-privilege “only these sources → these destinations/ports” feasible. That’s effectively microsegmentation (overlay-level), and it’s one way ZT limits lateral movement per NIST’s ZTA guidance.
That’s a fair framing, with one important distinction.
Overlay ACLs give you network-scoped microsegmentation, not service-scoped Zero Trust (as intended in NIST 800-207). You’re limiting which IPs/ports can talk after a node is attached, not deciding whether a service path exists at all per identity and per session.
The crypto isn’t the issue - WireGuard keys are strong. The issue is scope. A node identity that grants network reachability is different from a capability-scoped identity that creates only explicit service connectivity. NIST also warns that IP-based enforcement tends to reintroduce ambient trust once a device is attached. In that model, lateral movement is reduced, not eliminated.
A simple litmus test:
- If authenticating gives you an IP and routes, you’ve built network trust with segmentation.
- If authenticating only creates explicit service paths, you’ve built Zero Trust.
Mapping this to Wireguard and overlays, I’d say:
- WireGuard + identity + ACLs = good overlay microsegmentation
- Identity-first connectivity (no IP reachability, no inbound listeners) = Zero Trust by construction
If you adopt the latter, the former becomes unnecessary for Zero Trust — because identity creates connectivity directly instead of attaching nodes to a network. Bringing it back to the topic, microsegmentation manages risk inside a network. Identity-first connectivity removes the network from the trust model altogether.
Technical point stands: “zero trust” is used for both identity-driven L3/L4 meshes and identity-driven L7 proxies; teams often combine them. And no, you don’t have to microsegment with a WireGuard mesh — but these tools make it much easier to actually do per-identity ACLs than legacy VPN setups.
The NetBird docs [1] talk about "Zero Trust" being defined by NIST SP 800-207 and NIST SP 1800-35. This is also one of the definitions Wikipedia describes, with only one (uncited) mention of BeyondCorp.
Anyway, I still have no idea how this stuff is supposed to be "zero trust". It seems to place almost complete trust in the external authentication provider and also in the agent software that's rummaging around on all the clients while, as Wikipedia puts it, "checking the identity and integrity of users" (perhaps by examining the purity of the their precious bodily fluids).
If you are reading this thread and think that’s an interesting project to work on, shoot us a message. We are always looking for talented engineers that are passionate about open source :)
I see Pangolin has a Self-Host Community Edition, doesn't that already give something over digital sovereignity for EU users? I am considering both for a migration from Tailscale, any suggestion on their differences?
For a Tailscale migration, NetBird is the direct swap. Pangolin won't give you device-to-device connectivity.
On EU sovereignty: NetBird is Germany-based and explicitly positions itself as a European alternative. Self-hosted gives full control with no callbacks to their servers. Pangolin is US/YC-backed, so while self-hosting gives you control of the data plane, the project itself is American.
Also, NetBird has a reverse proxy feature coming this quarter, which would cover the Pangolin use case within the same platform.
I recommend it the NetBird team is transparent and easy to reach. I switched from Tailscale a while ago (2y), went fully self-hosted, and upgrades across versions have been smooth, which tells me they care about the self-hosted, not just their cloud offering.
We tried netbird but could not get the client to register to a self hosted server. It ignored the setting or failed.
Good chance it was user error on our part.
Most of their documentation is very unclear about what is a cloud offering feature and what is possible using self-hosting. There are features not available on the community edition and you have to be very careful reading their doc.
Just putting it out there so people do not think it's an easy solution. It will require appropriate planning.
I do think its a more promising solution than headscale if you want to self host as it is a complete package, unlike tailscale where you need to modify registry keys to change the cloud URL and headscale is a simplified, non-multi-tenant signaler.
There is a dedicated page explaining the difference between selfhosted and cloud versions: https://docs.netbird.io/selfhosted/self-hosted-vs-cloud-netb...
You can also use profiles and set management URL in the settings through the UI. You can even switch between self hosted and cloud versions: https://docs.netbird.io/client/profiles
We also had a bunch of problems. The DNS resolution didn't work, and support was unable to figure out the reason.
A coworker reported domain access breaking when he went to office 1, but fixed itself when he went to office 2.
For a while, when you logged in with the wrong account, it was near impossible to replace it. This on is fixed now, but the entire thing still feels very much like paying for beta software.
I have endless DNS problems with Tailscale. So I am guessing it’s a hard problem.
It's like the haiku says:
It’s not DNS
There’s no way it’s DNS
It was DNS
Tailscale is the only non-self-hosted part of my setup now and this has bugged me since. I use a custom Nameserver rule to point all my subdomains to a Caddy container sitting on my Tailnet. Caddy handles the SSL and routes everything to the right containers. I skipped Tailscale Funnel on purpose; since these are just family services, I’d rather keep them locked behind the VPN than open them up to the web. This project looks promising as a replacement for my current setup and for its digital sovereignity of self hosting the server. I'm looking to manage several embedded devices remotely via Tailscale, but I've hit a major roadblock: the 90-day maximum expiration for Auth Keys. Constantly renewing these tokens is a significant maintenance burden, so I'm searching for a more permanent, 'set-and-forget' solution for my remote hardware.
Tailscale allows you to disable the expiration time - I do this for my gateways.
My other simplifier is having everything at home get a .home dns name, and telling Tailscale to route all these via tailnet.
can you please tell me how to disable expiration time? I see auth keys have an Expiration which says it "Must be between 1 and 90 days." I do use a custom domain name as well with a Nameservers rule to have all my services reachable as subdomains of my custom domain.
There is some confusion here because while you can disable node key expiration, you can’t disable auth key expiration. But that’s less of a problem than it seems - auth keys are only useful for adding new nodes, so long expiry times are probably not necessary outside of some specific use-cases.
Edit: in fact from your original post it sounds like you’re trying to avoid re-issuing auth keys to embedded devices. You don’t need to do this; auth keys should ideally be single-use and are only required to add the node to the network. Once the device is registered, it does not need them any more - there is a per-device key. You can then choose to disable key expiration for that device.
I want my CI containers created per branch/PR to have their own Tailscale domain, so logging them in is useful via non-expiring key. Only good option I've seen previously is to notify every 90 days when key expires.
The best way to do that is using an OAuth client. These don't expire, and grant scoped access to the Tailscale API. You use this to generate access keys for the devices that need to authenticate to the network.
We use this for debugging access to CI builds, among other things – when a particular build parameter is set, then the CI build will use an OAuth key to request an ephemeral, single-use access key from the Tailscale API, then use that to create a node that engineers can SSH into.
Access keys ideally should be short-lived and single-use where possible. https://tailscale.com/kb/1215/oauth-clients#generating-long-... has details on this flow.
Thanks, I'll soon get to try this out hopefully!
You can create an oauth client that can generate keys as you need them.
https://tailscale.com/kb/1215/oauth-clients#generating-long-...
Use tag-based node authentication. Login as a user and then switch the device to use a tag. I just recently did that and retained the usual 6 months expiry. I can also disable key expiry completely.
You can manually disable key expiration for hosts in Tailscale, and I think you can do it with tags too...
https://tailscale.com/kb/1028/key-expiry#disabling-key-expir...
The word "auth keys" meant nothing to you, I guess: https://tailscale.com/kb/1085/auth-keys
What would be your use-case for auth keys with long expiry times? Auth keys are only required for registering new nodes.
When managing your infrastructure as code, it’s quite common to deploy new instances for upgrades etc. Having these keys expire after 3 months is a big pain. Eg doing a routine update by rebuilding an AMI.
I don’t understand how they can have such a strategy, and then not having any decent way to programmatically allocate new keys.
Yeah, that's a common workflow. It's easy to programatically allocate those keys using the OAuth workflow though – there's even a CLI utility to do it (https://tailscale.com/kb/1215/oauth-clients#get-authkey-util...)
This can all be automated using e.g. the Terraform Tailscale provider, which takes the OAuth id/secret and can then issue keys as needed for the infrastructure you are deploying.
Headscale is a self hosted drop-in control plane replacement that has been pretty stable for us.
+1 for caddy in Tailnet, working well for us too!
Long-time ZeroTier user here. Recently switched to NetBird (self-hosted on a Hetzner VPS) and it’s been seamless so far. DNS functionality is excellent (something ZeroTier lacked), and the access-control model is very well designed. It’s easy to understand what’s going on and to grant one-off access when needed. Only real and very minor gripe is the Android app: I wish it were on F-Droid and a bit more robust, as it sometimes drops when roaming. Nevertheless, congratulations on a fabulous piece of software! I hope it keeps improving :)
Does Tailscale/ZeroTier/Netbird provide anything beyond a GUI wrapper for Wireguard?
How easy is it to make it manage an already configured Wireguard mesh network?
As other have pointed out, Tailscale and Netbird are much more than wrappers around Wireguard. ZeroTier does not use Wireguard and they have their own lightweight tunnels, which in their recent multi-threaded implementations are more performant but not as fast as Wireguard in my testing.
I don't think there's a direct way to integrate any of them into existing mesh networks, but I could be wrong.
I had to use tailscale to bust through port forwarding on chained routers because, even with ports configured correctly, wireguard wasn't able to get through.
My use case was for remote access into a home-hosted Nextcloud instance, via an ISP supplied fibre router (IPv4, not CGNAT), then my own Gl iNet router, then to my Nextcloud instance.
Despite opening up port forwarding correctly, wireguard just couldn't get through that chain, whereas tailscale got through with no problems.
Downside of using tailscale is that it's messy to use at the same time as a VPN on your client device. Split tunnelling supposedly works, but I couldn't get it going.
Tailscale's strength is getting through double CGNAT of big ISPs.
Still requires your self-hosted VSP that is NOT behind a CGNAT.
They are not only a wrapper for Wireguard even though people keep saying that.
Each of the tools gives different benefits and yes, you can roll all of that on your own, but let's take Tailscale as an example: You have custom ACLs to secure your network on a client/user/device basis with tagging of devices. You have your own tailscale SSH connection, the possibility to create private-public tunnels (just like Cloudflare tunnels). The hole punching using DERP servers and native IPv6/IPv4 interoperability means it really connects any device on any network type to all other devices. And of course the management pane and GUI you talked about.
This is not supposed to be a marketing ploy for Tailscale, but saying "they are just a wrapper for Wireguard" is plain wrong.
I've been using jetbird from fdroid. I have never tried the official app, but I have good experiences with Jet Bird.
Thanks! Will try asap
But paid Tailscale is $5 a month right? So you gotta be paying more to self host and deal with all the problems yourself, not have derp servers all over the world, etc. Why?
If you run multiple services it gets cheaper. I would not see a reason to pay for 3 different cloud services that I am able to self host.
Why do you assume OP paid $5 a month? You get Tailscale for free in many use-cases. Your argument that self-hosting is more expensive is still valid, but I don't get the 5$.
tl;dr: because I can.
I already run a VPS for other things, this fits cleanly into that setup, NetBird’s been low-maintenance, and I don’t need global relays. That’s enough for me.
Also long time zerotier user here, I run a controller for our company. I'm starting to experience infrequent but annoying drops in connection, and DNS is a headache.
How is netbird on iOS?
I switched from Zerotier to Tailscale last year and Tailscale is far more performant and stable but Zerotier works better with multicast, specifically multicast video. I even ran a Zerotier moon to help but it was still worse than Tailscale.
I've been working for a while on https://github.com/connet-dev/connet. It gives a different twist at the same problem - instead of an overlay network at L4 (wireguard, etc) or publicly accessible endpoint at L7 (like ngrok) it "projects" a remote endpoint locally (e.g. as if you are running the service on your computer). Of course "locally" can always be a VPS that has caddy in front to give you ngrok-like experience.
The reason connet exists is that nothing (at the time I started, including netbird, tailscale/headscale, frp, rathole, etc) gave the same easy to understand, FOSS, self-hosted, direct peer-to-peer way of remote access to your resources. I believe it does accomplish this and it is self-hosted. And while a cloud deployment at https://connet.dev exists, it is nothing more then repackaging the FOSS project with user/token management.
This is meant just for computers, right? A quick check of the readme showed that devices must run this or that commands, which seems difficult to do on an smartphone. I guess the ngrok-like setup would be the way to go for that case, given the increasing prevalence of phones and tablets as the single form of computing for lots of people
I've been thinking a lot about this case specifically. And you are right, phones are largely not supported right now - I've been researching how to make that happen. One case I've found that works for me currently is running connet via Termux - and I've made the necessary changes to support that.
Native iOS/Android clients, if possible, will probably be the next things I'll work on. At minimum they should enable you to run a "source" (e.g. a consumer of an exposed service), but ideally it will be the whole deal.
A neat idea, but projecting all of these services onto localhost is a bit of a security nightmare. Have you considered looking at what something like Twingate does? Using the CGNAT IP space for the projection allows you to give every individual service its own IP address, which helps quite a bit in terms of allowing you to isolate the services from e.g. malicious web pages.
Me seeing "Request a Demo" button -> immediately leaving.
I'll take a look at what twingate does for sure, thanks for pointing that out.
A few things that worth mentioning for connet's current state - you can technically bind to any local IP, not just loopback (or listen to them all). You also have the option of directly running a TLS/HTTPS destination (for mutual TLS directly to the service) or source (e.g. for mutual authentication between your local listener and the outside world). Another option is to build your own client and define how you want to source traffic - maybe its part of your app and there are no sockets or anything - you just connect and start talking.
(Shamless plug) I am also working on a similar FOSS, self-hosted project called Octelium https://github.com/octelium/octelium that you might find interesting if you are interested in this space. Octelium is, however, more of a generic/unified zero trust secure access platform that can operate as a remote access VPN, a ZTNA platform, API/AI/MCP gateway, a PaaS, an ngrok-alternative and a homelab infrastructure. It provides unified client-based as well as clientless access for both humans and workloads; dynamic identity-based secretless access (e.g. access to HTTP/gRPC/k8s upstreams without sharing API keys and access tokens, SSH without distributing passwords/private keys, postgres/MySQL databases without sharing passwords, etc.); dynamic L7-aware, identity-based access control ABAC via CEL and OPA as well as dynamic routing to upstreams via policy-as-code; native Passkey login/WebAuthn/TOTP MFA and support for OIDC/SAML IdPs, OpenTelemetry-native L7-aware visibility and auditing; clientless access via OAuth2 for workloads, WireGuard and QUIC tunneling with dual-stack and automatic private DNS, including in rootless mode; passwordless SSH'ing into containers and IoT without SSH servers; deploying and securing access to containers; declarative k8s-like management with horizontal scalability among other features. You can read more in the README if you're interested.
It took me too long to understand the difference between the two so I'll leave it here for others. Octelium operates on OSI Layer 7 and Tailscale operates on OSI Layer 3 and 4.
Well, yes, Octelium is technically a VPN from a layer-3 perspective since it uses WireGuard/QUIC tunneling, but the tunnel doesn't directly terminate to the destination like in VPNs but instead to an identity-aware proxy that does authentication and L7-aware authorization on a per-request basis with policy-as-code via CEL/OPA. From an architecture perspective, I assume it's closer to ZTNAs such as Cloudflare Access and Teleport than to traditional VPNs, even though it operates as one for the clien-based access mode. However, unlike VPNs, it does provide clientless/BeyondCorp access too as it's intended to operate as a more generic/unified access platform (e.g. API/AI/MCP gateway, ngrok-alternative, PaaS-like platform, etc.) rather than just a VPN.
doest it have identity-aware proxy built-in?
Yes, every resource that needs to be protected is represented by a "Service" that's implemented as a L7-aware identity-aware proxy in the Octelium Cluster, which is a distributed system that's running on top of a k8s cluster. Users simply access the protected resource/upstream through the Cluster, namely the Service, from a data-plane perspective, and the Service/identity-aware proxy does authentication/authorization/routing/visibility on a per-request basis. This upstream could be an internal resource directly accessible by the Cluster, or remotely behind NAT, or simply publicly protected SaaS resource (e.g. API protected by an access token, SaaS database protected by a password, etc.). You can read more about how Octelium works here https://octelium.com/docs/octelium/latest/overview/how-octel...
[dead]
I've been keeping my eye on this one, it's very interesting.
Feel free to ignore this, but, what's your long term plan here? I see you have Enterprise plans (especially that allow different licenses). From what I can tell you're the only contributor, but, I assume that if you accepted contributions there'd be a CLA?
Thank you, I haven't accepted any contributions so far primarily because of this reason but things might change in the future. As mentioned in the README and docs, Octelium is designed specifically for self-hosting so the commercial side of the project is simply confined to commercial AGPLv3-alternative licensing, support, and other very enterprise-y/customized features such as SCIM, SIEM to specific providers, etc...
Do you foresee this changing anytime soon? Would love to contribute but also I think community adoption and contribution would go along way in terms of businesses less worried about single points of failure.
It’s hard balance to strike for sure. And it’s getting weirder by the day with agents.
Please don’t put SCIM behind enterprise licenses, it makes IT Administrators life hell.
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.
https://headscale.net/stable/
Could you give a brief description of your use case? I'm looking at all the tailscale buzzwords on their site, but am not really understanding what I would use this for in my home setup
Not sure about the parent, but here's what I use it for:
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.
Hamachi is layer2 (like zerotier)
Wireguard, talescale, netbird, etc. are layer 3.
Ah, correct, https://devilutionx.com uses it for that specific reason.
Hamachi is still a thing, but LMI enshitified a decade ago.
I run it on all my vps and allow me to close every port but 80 and 443, even port 22 is closed
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
I have some servers sending their telegraf data to a server in my home using the tailnet instead of opening a port on my firewall for that, to name one use case.
It has a pretty good ACL functionality, you can configure which hosts with certain tag can access certain routes.
yeah the amount of nodes I had on the public internet, when all I really needed was some internal connectivity (exactly like you have here, a machine sending logs to an internal-only loki instance, and then a grafana node that is also only internally relevant and never needs to see the public internet), etc.
I have one VPS node that I use as a connector, where the headscale app is installed. I have this on a domain (for convenience), so think something like:
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.
Tailscale is based in Toronto I believe.
tailscale were based in Canada last time i checked. has this changed recently?
well the OP talks about headscale server (self-host) which will run whereever your server that you install it onto will be. You just use the tailscale clients.
if you self host immich, homeassistant or jellyfin you can access them while out as easily as you can on home wifi.
Headscale is good. We're using to manage a two isolated networks of about 400 devices each. It just works. It's in China so official Tailscale DERPs do not work, but enabling built-in DERP was very easy.
headscale is an awesome project. And I love tailscale as a product.
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.
> 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?
can confirm that connections do not die while taking the coordinator down during update (not long time, but still)
Headscale mostly works pretty well but its pretty finicky to get set up in a way where the tailscale clients on linux and android aren't always complaining with warnings or having route or DNS issues. I'm considering investigating one of these non commericial solutions where the entire stack was built to work together.
Apparently they've deprecated Postgres support and now only recommend sqlite as the storage backend. I have nothing against sqlite but to me this looks like Tailscale actively signaling what they think the expected use of headscale is.
https://headscale.net/stable/about/faq/#scaling-how-many-cli...
> 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.
Why? Makes perfect sense to me. Designing a product with a specific use case in mind is good. When you've got the limited resources of am open source volunteer project, trying to solve every problem is a recipe for burnout. If it can even be done.
> Headscale is not enterprise software
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.
I dont understand what these two have to do with anything? The db-use is almost trivial, and SQLite can be embedded. Why would we want wasted effort and configuration complexity on supporting postgres?
[flagged]
With that kind of logic you wouldn't need headscale and would just ask your favorite LLM to write a similar tool for your with your own requirements and nothing else.
No, not really necessary to extrapolate the logic any further. You have deemed a very specific and focused task as "wasted effort." So the logic leads to putting in the effort you do not find "wasteful" and outsource the remainder to the LLM do this very specific thing.
Tailscale itself only uses sqlite[1], so I’m not sure if that really holds in this case.
[1]: https://tailscale.com/blog/database-for-2022
TIL! My problem with them requiring sqlite was that I assumed it would make a high availability setup either hard or impossible. Maybe that's not true, but definitely off the beaten path for headscale.
Headscale only supports a single control node.
I suppose there's always the old fashioned way of using drbd with heartbeat
[dead]
Yeah, Headscale people don't hide that it's a toy. I didn't get a homelab full of datacentre-grade equipment because I want to use toy, nonscaling solutions with vastly incomplete feature sets, but for the exact opposite reason.
On a different note; the HN obsession with SQLite these days is getting a bit tiresome.
Any luck using with with a VPN like Mullvad as an exit node?
I've done this a few different ways.
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.
According to its own documentation: https://headscale.net/stable/setup/requirements/
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.
Read the docs more closely.
- 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
>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.
Well, it also lets you federate access and manages the keys for you. But yeah, if it’s a personal setup and you have good key rotation hygiene, I agree with you: it doesn’t add much value on top of wireguard. I’ll hazard a guess that you can just run your own DERP relay too for the CGNAT case.
80/443 is all that's necessary for Headscale as a control server.
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).
Is Headscale suitable for production use?
I'd say no, but it really depends on what your use is. The biggest barrier is that it doesn't have a HA story that I'm aware of, but you might be able to get one by carefully replicating the sqlite and using something like pacemaker to fail over and fail back.
That said, I've been using headscale on 220 devices for ~3.5 years now and it's been quite reliable.
No, it's only viable if your whole network is, like, five devices.
I assume this is an exaggeration? Another poster says they have good luck with headscale on two networks of 400 devices.
yeah looks like someone is either a hyper tailscale fan or had extremely bad experience with it, I also run several dozens of machines (and tablets and phones) on it. never had a single moment of downtime since I started.
Looks good, congrats on progress.
are OpenZiti, Headscale, Nebula the 3 closest?
great resource here (no affiliation) for HN community:
https://github.com/anderspitman/awesome-tunneling
I like Netbird, its a better VPN, but its not zero trust networking. Zero Trust requires identity to create connectivity itself—per service, per session—rather than granting network reachability and constraining it with routes and rules. I have had this conversation on Reddit many times... curious if anyone agrees/disagrees.
I think the desktop client can authenticate to an IdP by opening a browser window and doing a login flow.
If the user is forced to authenticate to start the VPN session, would that make it zero trust?
I think once the VPN is on, it's on, and the remote service cannot get identity info from the network layer.
Seems like what you want to achieve can only be built on the application layer?
Short answer: no, authenticating to start a VPN doesn’t make it Zero Trust.
Once you authenticate to a VPN, you’re granted network attachment. From that point on, the network is effectively saying “I trust you enough to route packets,” and enforcement shifts to IPs, subnets, and firewall rules. That’s still network-level trust, even if the login was strong.
Zero Trust (architecturally; check out NIST 800-207) changes what identity does:
- Identity doesn’t just gate entry - Identity + policy decide whether a path exists at all, per service, per session - If you’re not authorized for a service, there is literally no route, IP, or port to talk to
On your last point: it’s not “only application-layer,” but it’s also not traditional L3/4 networking. It’s an overlay where identity is bound into connection establishment itself (mTLS/E2EE, service addressing, no inbound listeners), so the network never becomes a trust plane in the first place.
That’s the difference between “authenticate, then connect to a network” and “authenticate to create connectivity.”
For a reference, check out OpenZiti, thats a project I work on - https://openziti.io/
it should have support for signing of the configuration that is sent out to all nodes by a key the administrator controls, and which is then whitelisted on all nodes by oneself. That way the central node is just a simple data provider/helper.
right now you are screwed if someone compromises your coordinator
NetBird doesn't require network reachability (it used relays for NAT traversal) and creates the keys itself. It doesn't do any routing. It uses wireguard underneath.
For someone who want to setup a private network between host/devices, I feel the dilemma is always:
1. Trust a third party like Tailscale by giving them the key to your kingdom, but everything is incredibly easy and secure.
2. Self-host but need at least one host with a fixed IP address and an open port on the Internet. What requires a set of security skills and constant monitoring. That includes headscale, selhosted netbird, zerotier or a private yggdrasil mesh.
You can conceal that open port with some form of port knocking. Though this does reinforce your "easy" point.
Also, if it's an UDP port, then using a protocol that expects first client packet to be pre-authenticated and not emitting any response otherwise gets you pretty damn close to having this port closed.
Thanks for the suggestion !
I looked into it but it seems that port knocking and Single Packet AuthZ literally open the firewall and expose the port when used.
Meaning it is great to reveal the SSH port when needed, do your business quickly and close it back when you are done. But my guess is those overlay networks need to port available all the time, so...
Port knocking should open up the port for the IP that sent the knock. Not for everyone.
When I look at these zero trust solutions need 80/443 for what seems some type of bootstrapping
Better it happens using the same approach wireguard takes (udp/stateless). Though I'm not sure if there's more than just bootstrap taking place, maybe constant routing updates etc
Why do you think thats against the principles of zero trust? Wireguard is a wire transport, it has no control plane... I think what you are alluding to is the centralised control plane which makes it possible to operate at scale (and much more).
You could use a solution that allows you to have E2E with private sovereign keys on the endpoint, as well as bring your own IdP/PKI, so the provider does not have your keys. Would that be good enough?
Sounds interesting. How is it different to tailscale (or headscale)? I was planning to setup tailscale to replace my custom wireguard setup.
A bit lower level than most things discussed here but on the topic of overlay networks, I’ve used nebula for years and can recommend it
https://github.com/slackhq/nebula
+1 on Nebula. I don’t know why it doesn’t get mentioned more as an overlay network option.
I've used it for some time, it feels very much like it is in maintenance mode.
You manage a PKI and have to distribute the keys yourself, no auth/login etc.
it's much better than wireguard, not requiring O(N) config changes to add a node, and allowing peoxy nodes etc.
iirc key revocation and so on are not easy.
Nebula just had a major release that added IPv6 support for overlay networks. Hardly maintenance mode.
The main company working on it now seems to be adding all the fancy easy-to-use features as a layer on top of Nebula that they are selling. I personally appreciate getting to use the simple core of Nebula as open source. It seems very Unix-y to me: a simple tool that does one thing and does it well.
Nebula does not require O(n) config changes for adding a node.
O(n) is only required for:
- active revocation of a certificate (requires adding the CA fingerprint to the config file)
- adding/removing a lighthouses (hub for publishing IPs for p2p) or relay (for going over p2p)
- CA rotation
AFAICT you and 'ysleepy are in agreement.
We are, wireguard needs O(N) updates to add a node to every other node.
This problem has been brought up in the OpenZiti community many times. I like Nebula, but it's not 'truly open source'.
What do you mean?
Referring to the previous person's comment, that you need to manage a PKI and have to distribute the keys yourself, no auth/login etc.
How does that make it not "truly open source"?
I made a shell script that does most of that for my needs.
Fair, I was being loose with my language. What I should have said is that it does not come fully featured open source, that you need to do a certain amount of rolling your own.
The same could be said for a webserver, a radius server, etc. I mean ssh "requires" a network to be remotely useful :)
Edit, since I can't reply sadly:
You're right, that was a bad example.
I can probably list at least a few dozen things that all require certificates though, which was really my point. Everything has dependencies.
Also if you just... Don't trust big tech, run your own CA.
Right, but if certificates are a fundamental part of your design, you should include the functional mechanisms to manage them imho (i.e., key distribution, auth/login). The developers created it, but they keep it in the commercial product. Other overlays which use PKI include those functions in the FOSS.
nah, I dont buy that. A network is not a functional requirement of SSH etc in your use case.
What about DNS integration? As far as I know, you can't resolve nodes by name (http://media-server), you have to use node's internal IP.
Nebula uses lighthouses instead of DNS for finding other nodes.
https://github.com/slackhq/nebula?tab=readme-ov-file#2-optio...
Yes, but when you connect your phone to a Nebula network, and go to http://media-server in your browser, the DNS won't resolve it to your desired node, because the phone client (same on desktop) didn't update DNS of the phone, so you'll have to use node's IP address.
That's what I've read (when evaluating Nebula), at least.
It doesn't automatically update, that's true. But I think the typical way to deal with this is to have a nebula subdomain. www.nebula.example.com instead of www.example.com.
I haven't thought about it, thanks
When your nodes are not very numerous, and their IPs are statically assigned, you can just have them in a hosts file, or even served by your normal name server if you're using a split-horizon configuration.
Editing hosts file seems unwieldy, and impossible on a phone without rooting it, AFAIK
> split-horizon configuration
Is it when your local router redirects media-server.mydomain.com to a local IP, and say Cloudflare DNS redirects it to your Nebula IP?
it his much complex to setup then wireguard based?
It is the easiest to setup and understand really. There are no users, just hosts and their keys.
What it doesn't offer is a gui or tool to handle copying/installing/revocating keys so you trade super easy setup for a handful of nodes to management overhead if you are scaling up and down regularly.
Going to mention my own project which aims to be 100% open source, free, and relies almost only on public infrastructure: https://github.com/robertsdotpm/p2pd
Basically, I'm building a framework for building NAT traversal plugins. Software like ngrok and P2P VPNs can then be built on top of it. Examples of plugins for the library include direct connect, reverse connect (connect back to you), TCP hole punching, and UPnP-based port forwarding.
The underlying network stack for the project was also built from scratch to better support IPv6 and multiple interfaces. This allows plugins to fully utilise the underlying network paths and interfaces on the machine. This took considerable time because most software simply uses the default interface.
I'm still in the middle of building the software so its not yet functional. But if anyone is interested throw me a star or an email at matthew@roberts.pm.
By the way I forgot to add: if anyone needs a list of public STUN, TURN, MQTT, or NTP servers I wrote a monitor for them last year and added a bunch of servers. This is basically the infrastructure I use for my P2P library. The public API is here: http://ovh1.p2pd.net:8000/servers or if you want to host it: https://github.com/robertsdotpm/dogdorm
https://github.com/netbirdio/netbird
F-droid inclusion seems to be stalled https://gitlab.com/fdroid/rfp/-/issues/2688
Having it in F-droid, vetted by their policies is kind of my benchmark for "software that is guaranteed to be not crapware."
That being said I'm rooting for the devs, having an alternative for tailscale+headscale would be nice, because as it stands it's kind of dependant on the goodwill of a for profit company (finite).
https://codeberg.org/bg443/JetBird appears to use the same core library (and is just a different Android frontend wrapper).
I recently brought my first app to F-Droid. It was not friction free, but I was able to do it within a few weeks. Seems they put not much effort into this, e.g. the basic check marks are not even checked...
I tried migrating our organization from Twingate to self-hosted Netbird for cost savings but couldn't get it working reliably for 10-15% of users. The client failed intermittently with no clear pattern to troubleshoot. It became very frustrating for our end users. My advice: if you're considering self-hosted Netbird, set clear expectations that it's best-effort QoS, not enterprise-grade reliability. There's no such thing as a cheap VPN.
Would you mind sharing more about the issue? We have enterprises running NetBird with thousands of users with near zero issues. Apparently it is usually other way around - people migrating from Twingate to NetBird because of the former solution instability. Well, that is from our experience.
I suggest trying NetBird cloud to eliminate a potential misconfiguration of the self-hosted instance.
DNS resolution failures occurred inconsistently—sometimes due to browser caching when accessing web resources, but often for no apparent reason. For some users, restarting or reconnecting Netbird resolved it; for others, it didn't. The fact it worked flawlessly for some users while barely functioning for others suggests client-side issues. We also saw sporadic failures in cron jobs (like DB exporters) that never happened with Twingate. We followed the Helm chart configuration exactly and properly configured the Network Load Balancer with appropriate timeout settings.
I have been using Netbird for my small company of 10 people for about 2 years. Users on slow connections complained that they could not stay connected with services reliably. I could not reproduce the problem as I mostly connected from very fast connections. I thought that maybe the users or their ISPs were to blame. And then one time I was using the wifi on a plane. It was a slow connection and I was connected to an RDP server. I could not stay connected. I also has Cloudflare VPN connected to the same server. It worked really well over the same connection. I went back ad forth many times as I had trouble believing how bad the Netbird connection was. Long story short, we are now completely switching over to Cloudflare VPN. It is free for first 50 users and is very very reliable, in our experience.
Check out OpenZiti. Its open source, runs at prodution scale, and recently someone who used to work at Twingate said OpenZiti is many times more powerful than TG.
OpenZiti is promising but their desktop and mobile clients are very incomplete.
The feature set varies greatly between platforms.
If you are supporting a single platform (example desktop windows) it could work. Even better if you have the resources to write your own clients using the SDK, like it's meant to be.
How are the mobile and desktop clients incomplete?? Tunnelers exist for Windows, Android, iOS, Linux, MacOS, and more - https://netfoundry.io/docs/openziti/reference/tunnelers/....
We evaluated it last August/Sept.
From memory: oAuth login flow (browser based) was only supported on the windows client. For a Zero trust solution, having the only auth truly supported be a permanent JWT/Cert on the machine is doing device authentication, not user authentication, thus completely failing your primary objective.
UX was overall atrocious. Our users could not comprehend it at all. It was deemed that a custom client was required to be made.
The SDK first approach was an overall major plus point, allowing for a full customization to a specific use case.
Don't get me wrong we were overall impressed with the technology and the architecture choices. It's not a finished product, but something that does all the infra and you just need to apply the final veneer on top.
Ahh, I see, thanks for clarifying. That was correct, now any OIDC-compatible identity provider (Auth0, Okta, Azure/Microsoft Entra, Google, Keycloak, etc.) is supported on all the tunnelers to my knowledge.
Lots of work continues to go into the UX, but I would note that we focus most of the UI/UX work into NetFoundry, our commercial product.
That is good news!
The problems we had is users could not reliably tell when they were connected/disconnected, how to initiate the login flow, get network status (why is that service not working, but this other one is?), tell to which router they were connected, etc etc. I know these are big asks, and I suspect a lot of these troubleshooting and status info are probably available in the commercial offering.
That being said I think OpenZiti/NetFoundry is in a different class entirely and any lurkers here should consider it for their use. It's not really the same thing as NetBird or Tailscale.
Yeah, definitely more on the commercial side of the product.
And agreed, I like NetBird/Tailscale/Wireguard, but they are better VPNs, not identity-first, zero trust overlays as OpenZiti/NetFoundry is. That's why companies like Siemens have adopted it and many more will.
Working with it in a 1k active users setup, super efficient and stable! Clearly a revolution comparing to historical vpn solutions!
But it's missing a tailscale funnel like feature, right? That's one of the main features that I use for some home assistant instances.
Please be aware that when you use tailscale funnel you announce to the whole world that your service exists (through certificate transparency), and you will get scanned immediately. If you don't believe me just put up a simple http server and watch the scanning request come in within seconds of running `tailscale funnel`.
Do not expose anything without authentication.
And absolutely do not expose a folder with something like `python -m http.server -b 0.0.0.0 8080` if you have .git in it, someone will help themselves to it immediately.
If you are aware of this, funnel works fine and is not insecure.
Tailscale IMHO failing in educating people about this danger. They do mention in on the docs, but I think it should be a big red warning when you start it, because people clearly does not realise this.
I took a quick look a while ago and watching just part of the CT firehose, I found 35 .git folders in 30 minutes.
No idea if there was anything sensitive I just did a HEAD check against `.git/index` if I recall.
https://infosec.exchange/@gnyman/115571998182819369
Out of curiosity, why? I use TS for all my homelab bits (including my HA instance), but connect to TS before opening the HA app. Is it just a case of making it easier/ possible to connect if you’re on another VPN? Are you not concerned with having something from your local network open to the internet?
I use funnels for things like Vaultwarden, that are secure enough to be exposed on internet, and would be cumbersome if behind the tailnet.
I use serve for everything else, just for the clean SSL termination for things that should stay within the telnet, like *arr stacks, immich, etc.
After a decade with KeePass, I’ve finally moved to Vaultwarden. I’ll admit, self-hosting such a critical service still feels a bit scary, but the seamless syncing across all my devices is a huge upgrade. To balance the risk, I keep it tucked safely behind Tailscale for that extra peace of mind.
Ah neat, that makes sense. Thanks.
Do you have anything that’ll trigger a notification if there’s suspicious traffic on your local network? I may be overly paranoid about exposing things on my local network to the internet.
Not really, but these stuff are in an isolated DMZ vlan, so theres not much to escalate to.
I fancy a bit upgrading to a smarter router like unify's with integrated firewall and stuff like like though.
Besides the use cases listed, we see this as an opportunity for homelabers and organizations to add authentication with access control to already exposed services.
We are developing a similar feature and is scheduled to be available really soon. We've discussed some details in our public slack. Any feedback there will be helpful.
Agree, I use funnels and serves a lot as well. Very useful for homelabers.
I was previously using headscale and was finding it a bit finicky. Recently switched to self hosted netbird and its been great so far. However, if the Netbird teams sees this, please implement a built-in updater for the client apps! needing to download and install the package again is a bit annoying
Why not use a package manager? It seems way better than letting every app auto-update itself
I wish they'd chill on the release schedule and keep it to once a week or less. I keep it maintained in my Gentoo overlay but oftentimes when I go to bump it, they push another release. Since this submission was posted they've had yet another new release.
Met the founders in Berlin and was quite convinced of technical depth and vision. Great to have a European alternative to tailscale.
I've looked without success for external audit reports of either Tailscale and Netbird, like Mullvad gets. While I don't approve of the sort of auditor box-ticking we get at work, it would be reassuring to see a report from a proper security consultancy.
Netbird has supposedly done a penetration test, but it is only supplied upon request [0]. I haven't bothered trying to get my hands on it since I don't use their product. I don't agree with gatekeeping the results instead of making them public.
NetBird should also consider publishing an SBOM, similar to what Defguard does.[1].
[0] https://trust.netbird.io/
[1] https://defguard.net/sbom/
Oh, I hadn't found that. Yes, it seems strange not to publicize something like that to give users confidence (assuming the audit/pentest isn't damning). It doesn't have to have been perfect initially, as long as appropriate fixes were made.
I can't tell if Netbird provides this feature but looking at their access control feature it doesn't seem to.
I just want a roaming access Wireguard terminating endpoint to restrict access to a user to initial subnets, and open / allow routing to further subnets based on multi factor authentication. That way a user can connect and only have access to say a wiki and internal chat, but then escalate access by MFA to access resources on other subnets that have stuff like internal gitlab and whatever other critical resources exist.
For those interested, I just found out that mycelium can, like yggdrasil [0], be used to create private overlay networks [1].
What could be used as an alternative to Tailscale, netbird, etc.
- [0] https://changelog.complete.org/archives/10478-easily-accessi...
- [1] https://github.com/threefoldtech/mycelium/blob/master/docs/p...
We just evaluated this the other day and we were pretty impressed by it. We were looking for something we could self host for wireguard config but tbh we might just pay for the managed solution.
Using it self hosted for almost a year now, no issues, just works for me.
That is awesome!
Has anybody looked at whether Tailscale is subject to the US CLOUD Act? If so I can imagine we might be moving towards an open source solution like this in future.
Tailscales founders are Canadian, principled, and are very sensitive to Canadian needs. I very much trust Avery and team to do what’s necessary to keep US hands off the data.
edit: someone pointed out they’ve signed new users on to a US co. 15 months ago. I made the statement without knowing this. they aren’t as capable as I originally claimed.
According to their ToS all customer accounts registered on or after September 3, 2024 are signed on to a US company, so no they're not doing what's necessary to keep US hands off the data.
Thanks, good spot indeed. Just emailed our AM to find out what the situation is.
Very good discovery. My prior perspectives need updating.
So.... Any account from before then is always good? Or is it about the tailnet creation date?
I've head Netbird running for the last few months... In general it works quite well, but it would keep messing with my dns-resolving, and I couldn't find the setting to stop it inserting itself into my resolv.conf.
During the last few weeks I've removed netbird from all my systems (about 12), mostly because of issues on laptops where resolving or networking would break after they moved to a different network/location.
Just for future reference, you can disable DNS management for specific groups [0].
You can find the option under "DNS > DNS Settings > Disable DNS management for these groups". Netbird will stop modifying the resolv.conf on those groups.
[0] https://docs.netbird.io/manage/dns#4-dns-management-modes
Can Netbird run the DNS resolver (so it can be used for the internal domain ONLY by systemd-resolved) but not alter the host's DNS settings?
It looks to me like the setting that tells Netbird to leave the system DNS alone is arbitrarily tied to the setting that causes it to run a resolver at all.
For the guys at Netbird, please create an entry in the https://wiki.nixos.org explaining how to use it with nixos.
- Tailscale has one entry - Pangolin is getting one
I would like to see, even if brief:
1. Getting started
2. Hardware requirements
3. Security considerations
4. Recommended architecture, like running in a VPS if it makes sense
5. Configuring a server
6. Configuring devices
7. Resources (links to read more on netbird)
Thank you from the home lab community
Anyone can contribute to the nixos wiki, why don't you get the page started?
Because I don't feel confident. I'm super green at VPN's and this kind of networks. I don't want to give the wrong advice.
I'm editing what I can, but you don't want to take my advice, it would be better if someone who knows does it.
The fact that I'm into home lab, doesn't mean I know specifically how to do this. And I'm just saying, when I go to the wiki, to pick up on one of the options, they are missing.
I don't know why the hostility for asking to add some docs
This is kind of a weird request, IMO.
If you're a homelab NixOS user, isn't it on you to try to answer these questions? A home lab is for learning, and if you don't want to do that, what's the point?
What's the advantage over running plain wireguard?
Much easier setup, management, permissions, meshing etc.
Last time I checked it couldn't do ipv6... in 2026?
Could be intentional: German privacy advocates really like that the limited ipv4 pool forces reusing IPs and prevents accidental imprinting a practically static address on a device.
Makes a lot of sense.
But self-hosting still require at least a public domain name [0], so here goes your privacy right?
- [0] https://docs.netbird.io/selfhosted/selfhosted-quickstart#inf...
> The VM must be publicly accessible on TCP ports 80 and 443, and UDP port 3478.
> A public domain name that resolves to the VM’s public IP address.
Since it already uses DNS it's disappointing that it hardcodes ports instead of using SRV records. IMO anything that can use SRV records should. It makes for a more robust internet.
The number of products that actually use SRV records is surprisingly low (besides some mailservers and kerberos)
Can't do IPv6 internally or externally? Internally there should be zero need for ~infinite addresses. Externally though I certainly hope all software is capable of operating via IPv6 at this point because otherwise it will only be increasingly broken.
Can't do it externally, kinda. Last year I succeeded in joining a device reachable only through IPv6 to a Netbird network, but their service would fail when I tried to configure IPv6 nameservers for it; the web UI did accept them fine though, they just didn't work. A shame, since I was otherwise fine with IPv4-only for the Netbird network.
IPv6 is coming soon to NetBird.
I have tried multiple different solutions of so called "zero trust networking". My personal favourite one is Netbird but.. it lacks one feature: switching between multiple setups (networks). I am helping to maintain some startups and it would be just nice to quickly change (or even better: have access to multiple at once!) networks.
> it would be just nice to quickly change (or even better: have access to multiple at once!) networks.
Accessing multiple corporate networks simultaneously from the same endpoint violates all sorts of access policies. If it doesn’t, the access policy is lacking. Even for startups.
And no, unless you build it and enforce it from the start, no one ever succeeds in bolting on a reasonably security posture after implementing all their other processes no one will dare touch.
I use Headscale with Tailscale clients, and the Apple TV is very nice to have. Netbird seems to be working on one but it’s not out yet?
I replaced Teleport by a bunch of various tools, and I had to chose between tailscale/headscale and netbird for the network connectivity. I’m pleased with netbird so far.
I had some weird bugs on a few old servers during the transition, and the support was helpful even though I am a small customer. We eventually switched to user space wireguard on those servers.
Marginally relevant as I am looking into Netbird and Headscale: Anybody can recommand a europe-based VPS hosting provider that gives you an IPv4 range (4-5 IPs) that I can route over headscale?
I'm really missing something like Cisco DMVPN. A VPN mesh between different routers where all routers have a connection to each other, so that all traffic doesn't have to pass through the hub. And that runs on a router, because all these solutions only run on a regular computer with a complete OS.
Check https://tinc-vpn.org/ it may run on your router if you're running openwrt or similar
Out of curiosity, why? Because you dont want to run software on users devices?
What is the issue with one Wireguard port open? You vpn to home LAN and everything is there.
The issue with these VPN companies is that they log data, you have to run an agent running as root, reliance on several other companies too like IdP, etc. Very large attack surface.
First of all, if you have a mesh you don't have to connect to home server to talk to other devices in the same network. They connect to each other.
Second it's super easy to add a new device. Managing wireguard keys is annoying.
Third I don't have to open the port, worry about ddns etc.
Finally, for me it allows me to manage my DNS easily and I can leave tailscale running at all times. Also good luck implementing ACL on your own.
I don't see an issue with them logging when I connect to my stuff. The convenience for me is worth it more than the risk.
If your devices are in one network like at home, you have all those things with Wireguard too.
Devices in home LAN all talk to each other, so you have a mesh network.
You need keys for your laptop, phone and remote devices only. Most nodes are in LAN and don’t need to even run VPN.
With plain Wireguard, you open a single port in a single device. With mesh VPNs you open tons of ports: several ports in coordination, STUN and relay servers, also every device runs a vpn server listening to a port.
You VPN to home and use your home DNS. Your enter ACL rules and DNS server in your router.
I use a mesh VPN but I’m thinking of switching back to Wireguard, my older setup.
I tried installing it and it was a pain, if you don’t use the very very default scripts. Also their scripts regenerate secrets and the setup is weird in general (you need a complicated rp configuration and scripts to generate the config files)
Most of the self-hosted zero trust solutions require opening 80/443. It would be nice if they could adopt Wireguards approach of using UDP only, and only responding if the request is valid.
Maybe it's possible without modification to Netbird to setup a staging network.
Always my problem with Tailscale and similar solutions is that I already run VPNs in my personal devices and especially with android devices, I need to switch between two VPNs, which I find a friction that I do not want. Does anybody know a solution to this?
Tailscale has some integration with Mullvad. If you have a Mullvad subscription you can use their servers as exit nodes without dropping your Tailscale connection: https://tailscale.com/kb/1258/mullvad-exit-nodes
Outside of the particular combination of Mullvad and Tailscale I don't think there is any other way apart from switching between the two.
Maybe I don't understand, but the tailscale Linux clients definitely supports multiple accounts. I use that to reach multiple headscale networks and a tailscale one. No issues for me using it this way.
Not elegant or performant but:
You could have a exit node that is setup only for that vpn that advertises it's routes. So connecting to tailscale gives you access to that network.
How does this compare to Tinc?
I'm aware of how old Tinc is, but I've yet to find anything compelling enough to get me to switch. Tinc is a little annoying to set up, but once it's going I literally forget about it.
All these higher level VPN/tunnel solutions are so popular but functionally I’ve only ever wanted layer 2 VPN. Inside the tunnel, I want the ability to reason about a remote network as if it’s local, not on a per-host basis.
I'm currently comparing it with pangolin and headscale for my small scale company infrastructure access. Been running headscale for my own setup for a while but maybe netbird or pangolin might be better for real production.
Pangolin recently added desktop clients for win/mac/linux[0] and the Private Resource feature (similar to Netbird's Network Routes/DNS), so it's starting to overlap with Netbird more and more.
That said, it seems focused on client-to-site (newt) connections, and I don't see support for client-to-client connections like Netbird’s SSH access. Also, their Private Resources don't seem to support TLS termination yet. (Correct me if I’m wrong!)
In my case, I have a k3s cluster running on Netbird with a Traefik ingress for TLS termination inside my home network. Thanks to netbird's P2P nature, traffic stays entirely local as long as I'm on my home WiFi. (I suppose one could achieve the same with a Netbird + Caddy + DNS-01 setup, too.)
[0] https://docs.pangolin.net/manage/clients/understanding-clien...
I am in the same position but currently using Tailscale and realize how important and critical it has become for my whole family infrastructure. A self-hosted solution which allowed me to use Nameservers and TLS termination as I currently do would be awesome.
We've deployed self-hosted NetBird on AWS ECS and we're quite happy with the setup and the outcome.
we love and support netbird at sliplane <3 https://docs.sliplane.io/private-networking/netbird
Missing some technical bits to be a true contender for me but I bet they are getting there. That said I've seen so many shadcn based scam sites that my brain starts associating shadcn with scams.
For example? Curious what is missing
It funnels and lets encrypt certs for me and I am really not a fan of the android client.
Got you. We are on it. One feature that is coming very soon is a reverse proxy .Similar to cloudflare tunnels. With auth, TLs, etc. Would it suffice?
+1 from me.
In general I would keep an eye on the path CF is following with warp: which is great, but since they are so big and in fast evolution, it is a bit of a mess (their doc is outdated and changes too frequently) not to count (literally) their support (free version, and our company's opinion only, of course) since on warp it is totally useless.
Roger that!
Would love to learn more around your android experience
Battery usage is like 10% higher than with tailscale over a day.
If the VPN connection would stay connected despite having it set up that way in the web UI.. It would be a good product.
Still haven't figured out how to do Termux on Android with netbird ssh yet.
can you please elaborate on this? I use termux on android with tailscale and it works flawless, is it not possible on Netbird?
The following documentation doesn't work obviously because it's not on path. I need to do further reading of the docs, but I haven't had time yet.
netbird ssh user@100.119.230.104 https://docs.netbird.io/manage/peers/ssh
If I simply try... ssh user@100.119.230.104 it asked for a password, but there is no password.
Netbird's flexibility with IdPs is really nice. I recently switched mine to Pocket ID. Overall, it's perfectly sufficient and lightweight for homelab use.
Thanks for your feedback. I have a question: What do you think about the number of containers in our quick start deployment? Was that a concern?
You’re from the dev team, right? Thanks for the amazing OSS!
Regarding the containers, AFAIK it's 5 for the core setup (dashboard/signal/management/relay/coturn) plus Traefik in my case. It feels like a bit much, but the services are almost stateless and not resource intensive even on my little VPS. The setup script (bash + envsubst) is so straightforward and thanks to good documentation, I’ve never found the setup confusing. (I use Renovate to keep things updated, but I’d love to know if there's a recommended update path.)
A couple of minor things I noticed: 1. the dashboard image isn't on ghcr.io. 2. the generated compose.yaml contains hardcoded values. It could be even better if it referenced values from a .env file instead.
By the way, are there any ways to support NetBird other than GitHub Sponsors?
Coturn is not needed in the new versions as STUN is embedded in the relay service now
Your usage is the best form of sponsorship haha
What is the industry opinion on ngrok? They seem to be in a market where their product is considered a commodity and there are many alternatives.
Its more a sharing (outbound proxy) solution than a VPN like Netbird is.
I immediately looked at this and thought it was a tailscale clone.
I looked further into it and it’s essentially the same.
Implementation over ease of use of wireguard setup. Peer to peer modeling. Mesh networking. "Zero trust".
However, what I find interesting is netbird has open sourced their _coordinator server_. This allows for self hosting to be end to end.
yes with tailscale there exists "headscale", but it’s clearly a side project that few people within the tailscale company maintain on spare time.
One of the fears i have with headscale is a sudden change in leadership at tailscale, then the support from tailscale dies. Significant divergence occurs between headscale coordinator server and clients. Enshittification occurs and now forcing those smaller use cases onto their SaaS.
I love tailscale/headscale but will definitely give this a try.
Sweet. Alternatives are always something good.
Finally Debugging slow queries without seeing what's happening inside the plan is just guessing
Anyone know who the board members are and/or major stakeholders?
Besides the solid product, Misha & Maycon are just great and friendly people to work with.
love it! :)
In the old days we'd just trade a few family members to keep as hostages.
How does this compare with Defguard? Also European but seems more featureful maybe?
Hi, Robert from Defguard here.
Defguard is a *Secure by Design* solution, which means security is important (if not more) then functionality. Lower latency or peer-to-peer communication does not automatically mean better security often it means a larger attack surface.
Defguard is also *the only solution that enforces MFA on every connection*, aligning with true Zero Trust principles never trust a user or device by default.
Why Peer-to-Peer Is Not Safer?
Peer-to-peer and mesh solutions can be faster because traffic flows directly between peers, but they almost always expose all components publicly and make it easier to hijack the network or inject unauthorized peers.
So what does Defguard’s Secure-by-Design Architecture mean?
1. Minimal gateway exposure
The Defguard gateway exposes only a WireGuard port. Compromising it would require a Linux kernel or WireGuard zero-day at that point, no solution is safe.
2. Isolated, stateless proxy
The only Internet-facing "application" component is a stateless proxy, deployed in a separate network segment. It has no access to the gateway, core, or internal resources.
3. Protected control plane
The core (control plane) runs strictly inside the intranet (local network that should not be exposed anywhere). No user data are exposed to the Internet or DMZ/other network segments. Also the MFA validation process is done in secure network segments (for example when doing MFA with Desktop + Mobile client biometry/faceID combined).
Why This Is Different from Mesh Solutions?
Most mesh VPN solutions expose their control and peer-discovery components publicly by design. This significantly increases the risk of compromise and peer injection.
So that's about it.
So would you say then that it’s perfectly safe to send plaintext traffic between services over Defguard instead of also using mTLS?
I still wish that Defguard had an option where peers only used the public gateway to retrieve their p2p ACLs from the control plane but otherwise traffic flowed directly.
Defguard as of my knowledge is a traditional VPN with a central gateway. NetBird is an overlay network with a full mesh capabilities. Though you can set it up in a gateway-like style with NetBird Networks but without opening ports and with HA out of the box: https://docs.netbird.io/manage/networks
what is the difference between netbird and tailscale?
The cofounder is a Russian national, studied in Moscow. Possibly worth massaging that into your threat model.
My favorite feature of netbird might be no search in the client
or network names literally overlapping in the "overlapping networks" tab
or maybe it's the need to toggle the network on and off a few times to get it to work
One of the few pieces of software I actually despise but have to use, and I use win11.
Tailscale is great and headscale is an important step to gain trust. However, headscale is useless without the clients, and Tailscale geoblock installing clients where they can. If the platform requires jailbreak for installing user-chosen software, as is the case with iOS, then it all becomes useless.
Open (preferably free software) clients without idiotic restrictions could be one of the main advantages for any competing solution. Does Netbird provide them?
Why would Tailscale seek to limit access to their clients, other than where required by law?
The Android client, at least is FOSS. It's hardly Tailscale's fault that people buy iOS devices.
I don't care why. They do nothing to circumvent this so they are not a reliable solution for those who have network participants using the restricted platforms.
There could be a million reasons, but not a technical one — "headscale client", for example, could exist in current hostile app stores, but there isn't one.
Your arbitrary, loosely-detailed complaints would apply to literally everyone, every app.
It's on f-droid, it's open source, you're being ridiculous. I'm not even sure you understand what you're asking for. The official, open source Tailscale client explicitly supports headscale servers.
It's the only app from the ones I use that my friends and relatives who already use iOS can't even install due to geoblocking.
If you don't see it as a problem means you're not affected and perhaps lack some empathy.
Yes, I understand the Apple ecosystem is a problem. But it's not an insurmountable one. Builds of Free Software exist on Apple Appstore and none of them exhibit this problem, unless they are tied to a commercial entity in the corresponding jurisdiction. The issue with Tailscale is that they use their open-source clients and headscale as means to gain user trust, but their solution is deficient due to everything mentioned above.
> I'm not even sure you understand what you're asking for.
I'm asking for a free software client to go with the headscale server that can be installed everywhere technically viable, without idiotic additional restrictions.
It's clear that it's you who don't really understand the crux of the issue (which you partially admitted by you "not even sure", but still), but it's somehow I who's ridiculous.
I guess I'll just say that I hope you share the blame with the appropriate parties whenever you are suffering through iOS entitlements and provisioning to publish or self-load it on your iPhone, since Netbird's iOS client is open source.
Though, maybe it's not doing business in the US, and maybe the app is not similarly geo-blocked.
Actually can you not just pull the app and then side-load it anyway? That's what I would do if I couldn't get Tailscale from the Play Store...
Maybe this comment helps shed light on who I think are real the cause of your ire. Frankly I strongly agree with Brad's comment on why they don't care to open source the iOS client like they do the Android one.
I'm not sure where you saw ire. The only direct negativity was aimed at restrictions themselves, which is the product of foreign policy of specific countries and Apple politics. I'm not angry at Tailscale, just disappointed and annoyed.
> Actually can you not just pull the app and then side-load it anyway? That's what I would do if I couldn't get Tailscale from the Play Store...
The issue is, even if it's possible (which I doubt, since the users in question are not in the EU), it's technically challenging and the whole point of using a VPN solution was connectivity, which, besides other things, facilitates me technically assisting others. Besides, where do I even get the iOS client to side-load?
The point of my initial post was to ask if Netbird suffers from the same deficiencies as Tailscale (which are a fact). The question still stands, BTW.
It's interesting how you seem to dance around understanding exactly why Tailscale is geo-blocked and then also try to act "curious" like Netbird will be different. And somehow, you can't or won't just go check for yourself if the app is available in your region. Hm.
And it's interesting how you miss that it's not me I was talking of, assume I own an iOS device to check anything and am in the same region where the Tailscale client is geoblocked. Not to mention how you mixed Google Play and Apple App store during the discussion. Hm.
Unfortunately Netbird is VC backed. :( So the service will enshittify very soon.
Glad it is open source so we can have "zero trust" in VC backed dev tools services.
[dead]
This is a bot account spamming LLM-generated comments. Probably to advertise their website.
Thats kind of wild, mostly because -- presuming it's correct, what bot is saying is actually valuable here?
Doesn't matter. Generated comments are verboten here.
Honestly no it is kind of nonsense. Nothing requires you to microsegment with wireguard meshes, for example.
Agreed WireGuard itself doesn’t require microsegmentation, as it’s just a tunnel. The point is the mesh products built on it tend to add identity + ACLs, which makes least-privilege “only these sources → these destinations/ports” feasible. That’s effectively microsegmentation (overlay-level), and it’s one way ZT limits lateral movement per NIST’s ZTA guidance.
That’s a fair framing, with one important distinction.
Overlay ACLs give you network-scoped microsegmentation, not service-scoped Zero Trust (as intended in NIST 800-207). You’re limiting which IPs/ports can talk after a node is attached, not deciding whether a service path exists at all per identity and per session.
The crypto isn’t the issue - WireGuard keys are strong. The issue is scope. A node identity that grants network reachability is different from a capability-scoped identity that creates only explicit service connectivity. NIST also warns that IP-based enforcement tends to reintroduce ambient trust once a device is attached. In that model, lateral movement is reduced, not eliminated.
A simple litmus test: - If authenticating gives you an IP and routes, you’ve built network trust with segmentation. - If authenticating only creates explicit service paths, you’ve built Zero Trust.
Mapping this to Wireguard and overlays, I’d say: - WireGuard + identity + ACLs = good overlay microsegmentation - Identity-first connectivity (no IP reachability, no inbound listeners) = Zero Trust by construction
If you adopt the latter, the former becomes unnecessary for Zero Trust — because identity creates connectivity directly instead of attaching nodes to a network. Bringing it back to the topic, microsegmentation manages risk inside a network. Identity-first connectivity removes the network from the trust model altogether.
Not a bot. No links, no promo.
Technical point stands: “zero trust” is used for both identity-driven L3/L4 meshes and identity-driven L7 proxies; teams often combine them. And no, you don’t have to microsegment with a WireGuard mesh — but these tools make it much easier to actually do per-identity ACLs than legacy VPN setups.
> the strict BeyondCorp definition
The NetBird docs [1] talk about "Zero Trust" being defined by NIST SP 800-207 and NIST SP 1800-35. This is also one of the definitions Wikipedia describes, with only one (uncited) mention of BeyondCorp.
Anyway, I still have no idea how this stuff is supposed to be "zero trust". It seems to place almost complete trust in the external authentication provider and also in the agent software that's rummaging around on all the clients while, as Wikipedia puts it, "checking the identity and integrity of users" (perhaps by examining the purity of the their precious bodily fluids).
[1] https://docs.netbird.io/use-cases/implement-zero-trust
[dead]
If you are reading this thread and think that’s an interesting project to work on, shoot us a message. We are always looking for talented engineers that are passionate about open source :)
Are you on the Netbird dev team? :)
[dead]
[dead]
[dead]
[dead]
There's also https://pangolin.net/ which is kind of similar, and I believe a YC company.
Does that have ties to the US? If so it's not playing in the same ballpark.
US citizens may not be aware, but due to POTUS "made and maintained in Europe" is becoming more and more important to EU.
I see Pangolin has a Self-Host Community Edition, doesn't that already give something over digital sovereignity for EU users? I am considering both for a migration from Tailscale, any suggestion on their differences?
They solve different problems.
For a Tailscale migration, NetBird is the direct swap. Pangolin won't give you device-to-device connectivity.
On EU sovereignty: NetBird is Germany-based and explicitly positions itself as a European alternative. Self-hosted gives full control with no callbacks to their servers. Pangolin is US/YC-backed, so while self-hosting gives you control of the data plane, the project itself is American.
Also, NetBird has a reverse proxy feature coming this quarter, which would cover the Pangolin use case within the same platform.
With regard to European sovereignty, I note that Netbird uses AWS.
Not quite similar tho. Pangolin is a reverse proxy, NetBird is p2p mesh for internal resources remote access
It is not only a reverse proxy (which is actually just traefik), see this blog post https://pangolin.net/blog/posts/1-15-0-release
Pangolin is a hub-and-spoke style network. They actually have some comparisons between Netbird and Pangolin https://pangolin.net/blog/posts/pangolin-v-netbird and Pangolin and Tailscale https://pangolin.net/blog/posts/pangolin-v-tailscale