What Is Tailscale: A Practical Introduction to P2P Private Networking

This is the first post in my Tailscale lab series. Later posts will walk through a self-hosted control plane, a web UI, and a domestic relay. But before typing commands, it is worth understanding the principles. Once you know how it works, troubleshooting later becomes much easier than blindly copying commands.

The Pain Point: What Are We Trying to Solve?

The scenarios are common: you are away from home and want to access your NAS, connect back to the office network, or route traffic through a cloud server. Traditional solutions all have annoying tradeoffs:

• Port forwarding / DDNS: requires a public IP and exposes services directly to the internet, which is unsafe.
• frp / reverse proxy: works for traversal, but every service needs its own rule, which becomes operationally tedious.
• Traditional VPNs such as OpenVPN/IPsec: centralized gateways, heavier configuration, and traffic often takes a long detour.

The shared problem is: they either depend on public IPs, force traffic through a central node, or require too much configuration.

Tailscale takes a different approach: all your devices log into the same account and automatically form a virtual LAN. Devices communicate peer to peer, as if they were connected to the same switch. No public IP and no per-service port forwarding required.

Core Principle: Control Plane and Data Plane Separation

Tailscale is based on WireGuard, a modern, fast, kernel-level VPN protocol. The clever part is that it separates the network into two planes:

• Control Plane: the coordination center. It handles device authentication, distributes public keys, and pushes access policies (ACLs). It coordinates only; it does not carry your data.
• Data Plane: devices communicate directly with each other using WireGuard peer-to-peer encrypted tunnels. Data does not go through a central server.

flowchart TD
    C["Control Plane
Authentication · key distribution · ACLs"]

    A["Device A
phone"]
    B["Device B
home NAS"]
    D["Device C
work computer"]

    C -. "coordination only, no data" .-> A
    C -. "coordination only, no data" .-> B
    C -. "coordination only, no data" .-> D

    A == "WireGuard P2P direct connection" === B
    A == "WireGuard P2P direct connection" === D
    B == "WireGuard P2P direct connection" === D

    style C fill:#dbe9ff,stroke:#2563eb,stroke-width:2px

The control plane helps devices “know each other.” After that, they communicate directly without routing traffic through the control plane. This is why Tailscale can be both fast and secure: traffic does not pass through an intermediate server.

What If NAT Traversal Fails? DERP as Fallback

P2P direct connections require NAT traversal. Some network environments, such as symmetric NAT or carrier-grade NAT, make this fail. In that case, traffic falls back to DERP relay, an encrypted relay node on the public internet.

The key point: DERP is only used when direct connection fails. If P2P works, DERP is not involved. Tailscale’s official DERP nodes are distributed globally, but latency can be high for users in China. That is why a later post in this series covers self-hosting a domestic DERP relay.

Official Tailscale vs. Self-Hosted Headscale

When using Tailscale, the control plane is hosted by Tailscale Inc. by default. That is enough for many people, but I want more control for several reasons:

Headscale is the open-source, self-hosted implementation of the Tailscale control plane. The clients are still the official Tailscale apps; you simply point the login server to your own Headscale instance. The rest of this series is based on self-hosted Headscale.

Concepts That Will Keep Appearing

These terms will show up repeatedly in later posts:

• Tailnet: your entire virtual private network.
• Control plane / data plane: coordination vs. actual communication.
• WireGuard: the encrypted tunnel protocol used for P2P connections.
• DERP: encrypted relay fallback when direct connection fails.
• MagicDNS: assigns memorable domain names to devices so you do not need to remember IPs.
• ACL: access control rules, deciding who can access what.
• Subnet Router: lets one device bridge its entire local network into the Tailnet.
• Exit Node: uses one device as the outbound internet exit, similar to a full-tunnel proxy.

What This Series Will Build

The prologue ends here. Next comes the hands-on part. I recommend reading in order:

1. Next: Adding a Web UI to Headscale: headscale-ui Setup Notes Headscale is command-line first. A web UI makes adding nodes, approving devices, and managing routes much easier.

2. Then: Self-Hosted DERP Relay: Stable Domestic 20ms Fallback for Headscale Move the fallback relay closer to you, reducing latency from 100ms+ overseas relays to around 20ms domestically. Includes source modification, self-signed certificates, and anti-abuse pitfalls.

3. Finally: Joining Devices to Self-Hosted Headscale: From tailscale up to headscale-ui Management The most common daily workflow: run tailscale up --login-server, approve the device, manage it in the web UI, and configure routes.

Goal of the series: a private network fully under your control, with a much better domestic experience. Follow along, and you will have a network that feels like your home LAN wherever you are.