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.
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 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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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 :)
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 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.
(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...
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
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.
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.
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.
“Zero trust” gets used for two different architectures, and it helps to separate them:
1) Identity-aware networking (L3/L4): you still get IP reachability, but enrollment + ACLs/routes are driven by identity/device state. This is the WireGuard-mesh family (Tailscale/headscale/NetBird/etc). It’s “zero trust-ish” in the sense that nothing is implicitly trusted and you micro-segment, but once you’ve joined the mesh you’re still doing network-level access.
2) Identity-aware proxying (L7): no raw network access; every request is authenticated/authorized per app/service/session (Cloudflare Access/Teleport-style). That’s closer to the strict BeyondCorp definition.
Both are useful, they just solve different problems. A lot of teams end up combining them: mesh VPN for ops/workloads + an L7 gateway for “human-to-app” access where you really want per-request identity + clientless flows.
On the “why 80/443?” question: if you want SSO, device authorization, and a management UI/control plane, you’re probably going to have some HTTPS surface somewhere. The data plane can still be UDP end-to-end; the control plane is what tends to live on 443.
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 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/
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.
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.
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.
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.
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 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)
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?
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.
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.
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.
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.
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.
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.
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.
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.
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].
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 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.
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.
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?
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.
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.
> 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.
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 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?
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).
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
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.
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.
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.
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.
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.
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'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.
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 still a thing, but LMI enshitified a decade ago.
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 were based in Canada last time i checked. has this changed recently?
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.
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.
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?
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.
I suppose there's always the old fashioned way of using drbd with heartbeat
Headscale only supports a single control node.
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.
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.
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.
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
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.
+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 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.
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.
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.
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.
Sounds interesting. How is it different to tailscale (or headscale)? I was planning to setup tailscale to replace my custom wireguard setup.
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.
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 :)
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 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.
(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...
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...
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
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
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.
You can create an oauth client that can generate keys as you need them.
https://tailscale.com/kb/1215/oauth-clients#generating-long-...
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 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.
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.
+1 for caddy in Tailnet, working well for us too!
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
“Zero trust” gets used for two different architectures, and it helps to separate them:
1) Identity-aware networking (L3/L4): you still get IP reachability, but enrollment + ACLs/routes are driven by identity/device state. This is the WireGuard-mesh family (Tailscale/headscale/NetBird/etc). It’s “zero trust-ish” in the sense that nothing is implicitly trusted and you micro-segment, but once you’ve joined the mesh you’re still doing network-level access.
2) Identity-aware proxying (L7): no raw network access; every request is authenticated/authorized per app/service/session (Cloudflare Access/Teleport-style). That’s closer to the strict BeyondCorp definition.
Both are useful, they just solve different problems. A lot of teams end up combining them: mesh VPN for ops/workloads + an L7 gateway for “human-to-app” access where you really want per-request identity + clientless flows.
On the “why 80/443?” question: if you want SSO, device authorization, and a management UI/control plane, you’re probably going to have some HTTPS surface somewhere. The data plane can still be UDP end-to-end; the control plane is what tends to live on 443.
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.
Working with it in a 1k active users setup, super efficient and stable! Clearly a revolution comparing to historical vpn solutions!
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 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/
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.
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.
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.
https://github.com/netbirdio/netbird
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.
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 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)
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?
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.
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.
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.
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.
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.
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.
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.
What's the advantage over running plain wireguard?
Much easier setup, management, permissions, meshing etc.
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
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.
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/
Finally Debugging slow queries without seeing what's happening inside the plan is just guessing
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.
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.
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?
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.
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
Using it self hosted for almost a year now, no issues, just works for me.
That is awesome!
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.
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.
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)
IPv6 is coming soon to NetBird.
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?
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 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?
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...
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).
Sweet. Alternatives are always something good.
what is the difference between netbird and tailscale?
How does this compare with Defguard? Also European but seems more featureful maybe?
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
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.
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...
In the old days we'd just trade a few family members to keep as hostages.
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.
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.
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.
Besides the solid product, Misha & Maycon are just great and friendly people to work with.
love it! :)
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.
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.
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.
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.
Not quite similar tho. Pangolin is a reverse proxy, NetBird is p2p mesh for internal resources remote access