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
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.
My other simplifier is having everything at home get a .home dns name, and telling Tailscale to route all these via tailnet.
https://tailscale.com/kb/1028/key-expiry#disabling-key-expir...
How easy is it to make it manage an already configured Wireguard mesh network?
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.
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.
I don't think there's a direct way to integrate any of them into existing mesh networks, but I could be wrong.
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.
How is netbird on iOS?
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.
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 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.
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?
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 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
It has a pretty good ACL functionality, you can configure which hosts with certain tag can access certain routes.
hs.mygreatplace.com
Now, when I install Tailscale client on any device (phones, tablets, Linux machines, proxmox nodes, etc.), I simply say: don't use the tailscale network for this, please route this over my own network, so you point it to hs.mygreatplace.com as a connectivity server, which is compatible to Tailscale, and that's it. It's officially supported by Tailscale, so that's great and makes it all work.
Then, when pairing for the first time, you'll get a link/code, click it and/or enter it on the hub basically (hs.mygreatplace.com) and it's paired.
That connection is up and will stay up now. So while that new device may be behind a firewall, I can always connect to it. You open Tailscale and see all your paired devices. They basically now get an additional internal ip (100.0.0.1, etc.) and you use that to ssh or connect to it.
I have a beefy Proxmox machine, and used to route many of these services out to the public internet through port mapping, but now I just leave them cut off entirely and only surface them inside of my private network. When connecting to these nodes (from iPhone, Laptops, etc.), there's zero configuration once it is set up, it auto-routes correctly and just acts like those nodes are on the internet, it's a dream.
It also automatically adds the node as a subdomain, so if you pair a proxmox node that runs grafana, and maybe has a hostname "grafana", it will show up and be always reachable as: grafana.hs.mygreatplace.com
It doesn't get much easier than that.
All that said, I HIGHLY recommend Tailscale for anyone who hasn't done much with private networking, just to try out first, and get used to it. Their free tier is very generous and I think they've got a fantastic next-to-zero-config product, truly wonderful. However, my concern was to be trapped with a $160m dollar VC-funded (US-based) company, when the inevitable rug gets pulled (as it always does, and as anyone should come to accept, if you've been on the internet for a minute).
So I was looking for alternatives, and headscale immediately worked out. Of course, Tailscale ever killing their client's ability to use your own infra will lead to a similar end result (dead end), but I am sure those things can eventually be sorted out by open source attempts and clients (which headscale has, I just haven't tried them out yet, https://headscale.net/0.25.0/about/clients/).
I had a Wireguard network before (which this essentially also is, but in a much nicer packaging), but always ran into config problems with the shared profiles and IPs and so forth, so this was just a simpler step.
Worst case, it all goes back to Wireguard.
But this is where netbird beats tailscale: coordinator server open sourced out/self hosted out the gate.
Headscale is currently maintained by a few tailscale employees on their spare time. Currently, Tailscale allows this to happen but clearly there’s some internal management of what gets downstreamed to headscale.
What I don’t like about headscale is that you can only host a single coordinator server as well. If I need to do maintenance on the server, it means an impact to the tailnet. It’s rare but annoying.
Any p2p connections should keep working for some time even if the coordinator goes down... right?
> Scaling / How many clients does Headscale support? > It depends. As often stated, Headscale is not enterprise software and our focus is homelabbers and self-hosters. Of course, we do not prevent people from using it in a commercial/professional setting and often get questions about scaling. > Please note that when Headscale is developed, performance is not part of the consideration as the main audience is considered to be users with a modest amount of devices. We focus on correctness and feature parity with Tailscale SaaS over time. [...] > Headscale calculates a map of all nodes that need to talk to each other, creating this "world map" requires a lot of CPU time. When an event that requires changes to this map happens, the whole "world" is recalculated, and a new "world map" is created for every node in the network. [...] > Headscale will start to struggle when [there are] e.g. many nodes with frequent changes will cause the resource usage to remain constantly high. In the worst case scenario, the queue of nodes waiting for their map will grow to a point where Headscale never will be able to catch up, and nodes will never learn about the current state of the world.
I find that quite interesting and it is one of the reasons I've not really considered trying out Headscale myself.
On a different note; the HN obsession with SQLite these days is getting a bit tiresome.
I started with a docker container that connected to both the VPN provider and tailscale. Now OPNSense is handing a few connections to the VPN provider at a couple locations around the world, and enforcing external traffic to be routed to the VPN connections via VLAN tags (untagged has direct internet access).
Using the VPN provider can either be adding a VLAN tag to a machine/container or connecting to a "vpn-{location}" tailscale exit node.
That said, I've been using headscale on 220 devices for ~3.5 years now and it's been quite reliable.
So instead of opening a port on my firewall for WireGuard, I must have these ports public exposed:
* tcp/80
* tcp/443
* udp/3478
* tcp/50443
I don't know about you but that seems the most insane approach. Even if HTTP-01 challenge is not used, you are still exposing 3 ports instead of 1 random-high port like 55555 for example.
Yeah yeah, you can use rever-proxy but still, you are exposing way more ports and services to the internet than just one port for WireGuard itself.
- TCP/80 is only required to answer let’s encrypt challenges for certificate issuance
- UDP is only required to enable DERP.
These are both optional.
It’s not surprising that there are additional ports required on top of Wireguard. 443 is likely for key distribution and management. If you don’t want PKI then you don’t need headscale; you can always distribute the keys yourself and just run plain wireguard
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).
are OpenZiti, Headscale, Nebula the 3 closest?
great resource here (no affiliation) for HN community:
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?
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/
right now you are screwed if someone compromises your coordinator
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.
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...
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
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.
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.
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
https://github.com/slackhq/nebula?tab=readme-ov-file#2-optio...
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.
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.
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 suggest trying NetBird cloud to eliminate a potential misconfiguration of the self-hosted instance.
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.
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.
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.
NetBird should also consider publishing an SBOM, similar to what Defguard does.[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...
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.
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.
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.
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
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.
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...
- 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
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?
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 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.
Maybe it's possible without modification to Netbird to setup a staging network.
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.
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.
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.
Outside of the particular combination of Mullvad and Tailscale I don't think there is any other way apart from switching between the two.
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.
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'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.
Still haven't figured out how to do Termux on Android with netbird ssh yet.
netbird ssh user@100.119.230.104 https://docs.netbird.io/manage/peers/ssh
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 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 that's about it.
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.
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.
Open (preferably free software) clients without idiotic restrictions could be one of the main advantages for any competing solution. Does Netbird provide them?
The Android client, at least is FOSS. It's hardly Tailscale's fault that people buy iOS devices.
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.
Glad it is open source so we can have "zero trust" in VC backed dev tools services.
US citizens may not be aware, but due to POTUS "made and maintained in Europe" is becoming more and more important to EU.
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
