Making Tailscale Faster

Original Article ↗ Hacker News Discussion ↗

Tailscale’s recent work on making its WireGuard-based mesh VPN faster has reignited debate over the trade-offs between a user‑space, cross‑platform dataplane and kernel‑level or hardware‑accelerated alternatives. Commenters highlight that while Tailscale excels at ease of setup, device onboarding, and NAT traversal compared with self‑managed WireGuard or IPsec, it still struggles to fully exploit multi‑gigabit links and can increase battery usage on mobile devices. There is also active interest in future directions such as better relay strategies, post‑quantum and hardware‑accelerated crypto, and richer support for routers, microcontrollers, and app‑free access models.

Platform focus & dataplane work

  • Discussion notes the blog post emphasizes Linux/Android because many packet-level optimizations are OS-specific and these platforms expose needed features.
  • Architectural changes like multiqueue and memory optimizations are said to be generally applicable to other OSes.

Performance, userspace vs kernel

  • Several commenters argue Tailscale is “slow,” citing difficulty exceeding 1 Gbps on desktop clients and ~10 Gbps on Linux in synthetic tests.
  • Critics say userspace networking with extra copies and context switches has an inherent ceiling and call for kernel WireGuard or DPDK/XDP-style zero-copy approaches.
  • Others counter that memory copies and syscalls are not the main bottlenecks; protocol and implementation choices matter more.
  • A Tailscale representative responds that kernel is not automatically faster; at one point their userspace WireGuard outperformed the kernel version, and high-end DPDK-style paths are userspace anyway.

WireGuard vs Tailscale vs alternatives

  • Some users switch from Tailscale to plain WireGuard, citing better stability, perceived speed, and simplicity given router integrations and simple key setup.
  • Others move in the opposite direction, praising Tailscale for trivial onboarding, dynamic device registration (including CI jobs), easy DNS integration, and working around NAT and port-forwarding limitations (e.g., relatives’ homes).
  • Cloudflare Tunnels are mentioned as an “app-free” alternative for some use cases.

Crypto, hardware acceleration & post‑quantum

  • Debate over whether Tailscale should diverge from WireGuard’s ChaCha20/Poly1305 to AES-GCM to leverage NIC hardware offload for 100–400+ Gbps.
  • Concerns raised that deviating from WireGuard’s carefully analyzed design loses formal guarantees; others argue swapping ciphers can preserve core properties.
  • IPsec is seen by some as overcomplex and historically finicky; others note it can be used with a simplified control plane and strong hardware acceleration.
  • Post-quantum support is discussed: some argue WireGuard v2 or an updated data plane is inevitable; others mention PSKs as a limited “quantum-resistant” stopgap.

Relays, routing & DERP

  • Complaints about DERP latency and desire for more flexible relaying.
  • Peer relay feature exists but currently requires the relay peer not be behind NAT; commenters want more opportunistic use of NAT-traversable peers as ad-hoc relays.

Client UX, battery & platform quirks

  • Multiple comments report high battery usage on iOS and when using exit nodes; users want to leave Tailscale connected continuously without major drain.
  • Apple TV exit-node performance is reportedly poor; OS aggressively kills background apps, limiting what Tailscale can do.
  • Some confusion/complaints about Android apps being excluded from VPN paths; others note Android allows apps to opt out, and “block connections without VPN” can mitigate leaks.
  • DNS privacy: request for DoH support; Tailscale notes that using a tailnet DNS server already keeps DNS queries private over the tunnel, while DoH adds TLS complexity.

Advanced/edge use cases & feature requests

  • Requests for:
    • Better story for microcontroller/IoT support.
    • Easier multi-node proxy/sidecar setup when devices can’t run Tailscale directly (today often requires one container per proxied device).
    • Clearer description of “queues” and “depth” in the blog’s networking diagrams.
  • Some users explicitly ask Tailscale not to “enshitify,” reflecting strong enthusiasm but also concern about long-term product direction.