Tailscale alternatives compared: Headscale, NetBird, Netmaker, Nebula, and splitting internal vs. external access

DNS, 100.64.0.0/10, iptables, MTU, ACL, SSO.
Tailscale is convenient, but it takes a lot of control over a Linux host’s networking.
Reading “I want to quit Tailscale” (Japanese) made me realize I had been thinking the same thing.

Looking back at my own setup, the config I wrote about in exposing a local LLM as an external API via VPN was exactly this kind of Tailscale dependency.
A VPS hits the home PC over a Tailscale IP. No NAT traversal headaches, and it still works today.
But that setup puts “reaching a closed service from the inside” and “exposing an API to the internet” on the same VPN tunnel.
That is why quitting is hard.

Swapping Tailscale for another product does not help if the access-path design stays the same.
Unless the road in and the road out are separated, any VPN choice eventually drifts back toward a full tunnel.

What people dislike about Tailscale is not WireGuard

Tailscale’s data plane is WireGuard-based, but the complaints rarely target WireGuard’s crypto itself.
The friction comes from Tailscale managing DNS, routing, netfilter, MagicDNS, and the 100.64.0.0/10 range all at once on Linux hosts.

Tailscale themselves wrote about the difficulty of handling DNS configuration on Linux in The Sisyphean Task Of DNS Client Config on Linux.
/etc/resolv.conf, resolvconf, NetworkManager, systemd-resolved all collide, so the implementation side getting messy is understandable.
Understandable, but from a user’s perspective it becomes “I installed a VPN and now my name resolution and firewall changed.”

On the netfilter side, Tailscale’s official documentation describes three modes: on, nodivert, and off.
The default on has Tailscale create rules and manage their evaluation for necessary traffic.
nodivert creates the rules but does not activate them.
off means Tailscale does not manage the firewall at all, and you write the needed rules yourself.

So there is an escape hatch.
But setting it to off means writing leak-free firewall rules on your own.
You bought Tailscale for convenience, yet now you are self-operating the dangerous parts.

The 100.64.0.0/10 problem is similar.
GitHub issue #12829 reports a case where installing Tailscale on a network that internally used 100.100.0.0/20 made it unreachable due to a DROP on the entire 100.64.0.0/10.
The CGNAT range is not just “ISPs only, so it’s safe” anymore. Kubernetes, VPNs, and internal corporate networks also use it as overflow space.
When a product grabs that range with strong assumptions, collisions with existing networks turn into sudden outages.

Headscale removes Tailscale Inc. but tailscaled stays

Headscale is a self-hosted implementation of the Tailscale control server.
Its official site describes it as “open source, self-hosted implementation of the Tailscale control server.”

This is quite effective for reducing SSO and Tailscale Inc. dependency.
It directly addresses the concern of entrusting a tailnet’s existence to Tailscale’s SaaS.

However, the client running on Linux hosts is still basically tailscaled.
If DNS, netfilter, 100.64.0.0/10, and MTU are the main battleground, switching to Headscale does not eliminate all of them.
If “Tailscale’s management plane” is the issue, Headscale helps.
If “tailscaled reaching into the host” is the issue, you need to look elsewhere.

NetBird and Netmaker are alternatives but do the same kind of work

NetBird is an open-source mesh VPN combining WireGuard, Pion ICE, Coturn, and others.
The management service, Signal, and Relay can be self-hosted, and clients connect directly via WireGuard when possible.
NetBird’s documentation also states that the client applies a Firewall manager and DNS settings.

This matters. NetBird being “more open than Tailscale” does not mean “it leaves the host alone.”
It solves the same problem space with a different implementation.
It can replace Tailscale if the implementation and operational philosophy fit, but for people who want to avoid software that touches DNS and firewalls, it is not a fundamental fix.

Netmaker also builds full-mesh or partial-mesh networks with gateways on top of WireGuard.
Its official documentation explains that it abstracts WireGuard’s ports, endpoints, keys, and peer configurations.
If you want to manage routes and gateways via a GUI, it is an option.

Both NetBird and Netmaker carry a management plane to solve the hassle of distributing WireGuard config files by hand.
Having a management plane means authentication, key distribution, route distribution, DNS, and ACL design come in somewhere.
If the complaint about Tailscale is “the management plane is a black box,” these are a step forward.
If the complaint is “I don’t want any software gripping my host’s networking,” they are still heavy.

Nebula is a bit old-school but its footprint is readable

Nebula originated at Slack and is described on GitHub as a tool emphasizing “performance, simplicity and security.”
It is not WireGuard-based. Instead, it uses a CA to issue node certificates and a lighthouse for peer discovery.

The upside is that it does not do much on its own.
Read the certificates, lighthouse config, static settings, and routes, and you can mostly tell what it is doing.
The downside is the same: there is no “install, log in, everything connects” like Tailscale.
Once mobile devices or non-engineer users enter the picture, the operational feel hardens quickly.

For a handful of personal servers, a few VPS instances, and fixed home machines, Nebula is a solid fit.
When family phones, a laptop on the go, and short-lived test VMs are included, a Tailscale-like solution becomes easier.

Cloudflare Tunnel is an exposure tool, not a VPN replacement

If all you need is to access home services from outside, Cloudflare Tunnel or a similar reverse tunnel may be enough.
Cloudflare’s Private networks documentation explains that cloudflared opens an outbound tunnel from a server inside a private network to Cloudflare, proxying user-to-server traffic.
This shape fits public web services, admin panels, and webhook endpoints.

But it is not a VPN.
It does not provide bidirectional LAN access over arbitrary IP protocols. The design is essentially creating an application entry point on the Cloudflare side.
Using Cloudflare WARP or Mesh can push it toward private network connectivity, but at that point you are leaning into Cloudflare’s Zero Trust platform.

In the earlier WireGuard VPN server setup notes, I compared a full tunnel with AllowedIPs = 0.0.0.0/0 and a split tunnel with 10.0.0.0/24.
The design here is basically the latter.
Home NAS, management SSH, local LLM, and DB admin panels go on the private route.
HTTP APIs exposed to the outside use a VPS, Cloudflare Tunnel, ngrok-like services, or a plain reverse proxy.

flowchart TD
  A[Laptop or phone] --> B[Closed management access]
  A --> C[Public API or Web UI]

  B --> D[Split tunnel]
  D --> E[Home NAS, management SSH]
  D --> F[Local LLM internal API]

  C --> G[HTTPS entry point]
  G --> H[VPS or Cloudflare Tunnel]
  H --> I[Forward only needed services]

With this split, the VPN side does not carry outbound internet traffic.
DNS does not redirect all queries to a MagicDNS equivalent; only internal domains use split DNS.
Routes advertise only the CIDRs you need to reach, not 0.0.0.0/0.

HTTP/3 and QUIC belong on the public-facing side

In VPN protocol comparison for China connectivity and VeilShift protocol DPI bypass differences, I wrote about Hysteria2, VLESS + REALITY, XHTTP, uTLS, and padding.
That was about making traffic look like normal web traffic to evade censorship and DPI.

For a closed management network connecting home and VPS, that level of effort is overkill.
Adding HTTP/3 masquerading or padding where plain WireGuard works just increases operational overhead.
HTTP/3 and QUIC matter at the public-facing web entry point, where mobile network performance, CDN, and edge handling are the concern.

For example, to use a local LLM from outside, the inside is fine with WireGuard split routes.
The outside terminates HTTPS at a VPS’s nginx or Cloudflare, with HTTP/3 enabled where possible.
The external face is a normal HTTPS API, and only the backend escapes through the closed route.
This way, the LLM server itself never faces the internet, and there is no need to distribute a VPN client to every user.

For immediate use, narrow Tailscale’s scope

When asked whether real alternatives exist, the answer is yes.
Headscale, NetBird, Netmaker, Nebula, raw WireGuard, and Cloudflare Tunnel can be combined to build something without Tailscale.
But a Tailscale replacement tends to become an assembly of parts rather than a single product.

For immediate use, narrowing Tailscale’s reach is more effective than ripping it out.
Turn off MagicDNS.
Stop using exit nodes by default.
Confine subnet routers to a dedicated VM.
If the CGNAT range is in use internally, isolate the hosts that run Tailscale.
Do not install it on Linux hosts with tight firewall management.

Tailscale’s userspace networking mode is another escape hatch.
The official documentation shows that --tun=userspace-networking runs it as a SOCKS5 or HTTP proxy.
This is primarily for containers and serverless, skipping the TUN interface at the cost of requiring the application to use the proxy.
It fits the use case of keeping Tailscale off the host’s network stack, but it is not a VPN that naturally enters all LAN protocols.

Tailscale is often more practical to isolate than to discard.
Do not install it on core routers, Kubernetes nodes, or servers with fine-grained firewall control.
Instead, place a small VPS or dedicated Linux VM at the boundary and route only the needed services through it.
Let Tailscale handle “instant connectivity” if you want, but do not let it own “where traffic flows.”