Tailscale is pretty useful

Original Article ↗ Hacker News Discussion ↗

Performance and protocol behavior

  • Several users see noticeable throughput loss on local networks, especially with Samba/SMB over Tailscale (e.g., ~10–15% drop on 1 Gbit LAN).
  • Suspected causes include user‑space WireGuard on Windows, MTU/fragmentation issues, extra encapsulation overhead, and occasional DERP relay usage instead of direct paths.
  • Others report WireGuard can easily saturate 1–10 Gbit with decent CPUs, arguing such large drops point to misconfiguration (MTU, routing, or Samba tuning) rather than inherent limits.
  • Tailscale adds ~1 ms latency on LAN for some, which can matter for chatty protocols.

Alternatives and self‑hosting

  • Many compare Tailscale to raw WireGuard, OpenVPN, and mesh systems like Netbird, ZeroTier, Nebula, Tinc, Hamachi, OpenZiti, and Headscale.
  • Headscale is highlighted as a self‑hosted replacement for Tailscale’s control plane, trading simplicity for managing availability and updates yourself.
  • Netbird, Nebula, and OpenZiti are noted for NAT traversal and more “zero trust” or app‑embedded models; ZeroTier for L2‑style networking and working where WireGuard is blocked.
  • Some feel mesh VPNs “just for NAT traversal” add too much complexity compared to a simple WireGuard server when CGNAT isn’t an issue.

Security, trust, and architecture

  • Big thread on whether to trust a managed control plane: concerns about compromise, metadata exposure, and non‑FOSS clients (for some alternatives).
  • Tailnet Lock and E2E WireGuard encryption are cited as mitigations; clients keep private keys, coordination servers only see public keys and metadata.
  • Some advocate an extreme “never trust providers” stance, layering client certs or app‑level auth on top of Tailscale, or preferring fully self‑hosted stacks.
  • Others argue Tailscale is safer in practice than home‑rolled VPNs many users would misconfigure.

Use cases and benefits

  • Common personal uses: accessing NAS, home servers, Jellyfin/Plex, SSH, Home Assistant, NVRs, and Pi‑hole from anywhere; LAN‑like gaming; remote family tech support.
  • Exit nodes frequently solve geoblocking, censorship, and hostile public Wi‑Fi / MITM (airports, cruises, hotels, work guest networks).
  • Enterprise uses: internal app access with ACLs, SSO/OIDC, device tags, Kubernetes operator, posture checks, and tsnet‑based internal apps.
  • Features like Magic DNS, automatic NAT traversal, multi‑OS clients (including TVs/routers), tailscale serve/funnel, and built‑in TLS cert issuance are repeatedly praised.

Limitations and rough edges

  • Reports of high battery use and instability on some Android/iOS setups, and memory issues on very small routers or older Pis (mitigated by “small binary” builds).
  • Missing features or pain points: lack of mDNS across the tailnet, no DNS entries for tags (group service discovery), tricky interactions with iptables/Docker and MTU, and being blocked on some restrictive networks.
  • Some see Tailscale as overkill for a single‑site home setup where simple WireGuard + port forwarding suffices, especially when CGNAT isn’t present.

CGNAT, ISPs, and philosophy

  • CGNAT is viewed as the main driver making Tailscale‑style solutions necessary, and as part of broader ISP “enshittification” (locked‑down routers, forced equipment, DNS hijacking).
  • There’s debate over whether such tools prolong IPv4’s life and slow IPv6 adoption versus being pragmatic workarounds in a hostile networking environment.