LFCE 92 🐧 Tailscale — Concepts - KandZ

⏱️ Estimated read: 12 min | |

Tailscale is a mesh VPN built on top of WireGuard. It takes the encrypted peer-to-peer tunnels that WireGuard provides and adds the coordination layer that WireGuard deliberately leaves out: identity-based authentication, automatic key distribution, NAT traversal, and a centralized control plane that tells every device how to reach every other device . The previous chapters covered WireGuard as a standalone protocol and OpenVPN as a traditional VPN; this chapter covers the managed mesh that sits on top of WireGuard and removes the manual configuration that the previous chapters required.

Quick How-To Guides & Fast FixesNeed a quick fix or step-by-step solution? Browse our fast answers on HowTo.KandZ.me:

Operating Systems CLI →Dev Environment Languages →Web Network Tools →Security Accounts →Security Access Tech →Device Phone Basics →Social Messaging →Digital Files Media →

The core architectural distinction is between the control plane and the data plane. The control plane is Tailscale’s coordination service, which stores the public keys of every device, distributes the peer lists, and enforces the access control policies. The data plane is the WireGuard tunnel on each device, which carries the actual encrypted traffic directly between peers . The coordination service never sees the data; it only tells the devices how to find each other. This separation is what allows Tailscale to provide the zero-configuration experience while keeping the traffic end-to-end encrypted.

Key point: Tailscale assigns every device a stable IP address in the CGNAT range 100.64.0.0/10, and the coordination service distributes the public keys so that every device knows how to reach every other device it is allowed to access . The connections are direct peer-to-peer WireGuard tunnels when NAT traversal succeeds, and they fall back to DERP relay servers when it does not . The coordination service is not in the data path; if it goes offline, the existing connections continue to work with the cached policies .

Why Tailscale exists

The NAT-traversal problem.

WireGuard requires each peer to know the other peer’s endpoint, which is a public IP address and port. In the real world, most devices are behind NAT, and their public address changes as they move between networks. Tailscale solves this with STUN and ICE-based NAT traversal, which discovers the public endpoint of each device and negotiates the direct connection . When the NAT is too restrictive for a direct connection, Tailscale falls back to the DERP relay servers, which are globally distributed and use HTTPS streams that can pass through almost any firewall .

The key-distribution problem.

Standard WireGuard requires the administrator to copy the public key of every peer into the configuration of every other peer. A mesh of ten devices requires ninety key exchanges. Tailscale automates this: the coordination service stores the public keys and distributes them to the devices that are allowed to communicate . The administrator does not manage keys; the identity provider authenticates the user, and the coordination service handles the rest.

The identity problem.

WireGuard identifies peers by public key, not by user. There is no concept of “Alice’s laptop” or “the staging server”; there are only keys. Tailscale adds the identity layer: each device is authenticated through an identity provider such as Google, GitHub, or Okta, and the access control policies are written in terms of users and groups rather than IP addresses . This is the zero-trust model: the network does not trust a device because it is on the local subnet; it trusts the device because the identity provider authenticated it.

a. The tailnet and the coordination service

A tailnet is the private network that Tailscale creates when the first device logs in. It is identified by a DNS name, and it contains the users, the devices, and the access policies .

# Check the status of the tailnet on a device
tailscale status
# Output lists the devices, their IPs, and the connection type

The tailscale status command shows the devices in the tailnet, their 100.x.y.z addresses, and whether the connection is direct or relay . The coordination service is the component that maintains this list and distributes it to the devices. It handles the authentication, the key distribution, the NAT traversal coordination, and the policy enforcement .

The coordination service does not carry the data traffic. When the device starts, it connects to the coordination service and receives the list of peers and the policies. The data then flows directly between the peers over WireGuard. If the coordination service becomes unavailable, the devices can still communicate with the established connections, because the keys are stored locally and the policies are cached .

b. The connection types: direct, DERP, and peer relay

Tailscale has three connection types, and the type determines the performance and the path .

A direct connection is a peer-to-peer WireGuard tunnel over UDP. It has the lowest latency and the highest throughput, and it is the preferred type. Tailscale attempts to establish a direct connection for every pair of devices, using the NAT traversal techniques that are based on STUN and ICE .

A DERP connection is a relayed connection through one of Tailscale’s globally distributed relay servers. It is the fallback when the direct connection is not possible, such as when both devices are behind hard NAT . The DERP server forwards the encrypted WireGuard packets without decrypting them, so the traffic remains end-to-end encrypted .

A peer relay connection is a relayed connection through another device in the same tailnet. It is faster than DERP because it avoids the geographic distance of the DERP server, but it is slower than a direct connection because it adds a hop .

The connection type is determined by the NAT type of both devices. The tailscale netcheck command shows the NAT type and the DERP latency of the local device . The tailscale ping command shows whether the connection to a specific peer is direct or relayed .

c. The exit nodes and the subnet routers

Tailscale can replace a traditional VPN in two ways: the exit node routes all the internet traffic through a device in the tailnet, and the subnet router exposes a local network to the tailnet .

An exit node is a device that advertises itself as a gateway for the internet. The other devices can choose to route their traffic through it, which is the equivalent of a traditional full-tunnel VPN .

# On the exit node
sudo tailscale up --advertise-exit-node

# On the client
sudo tailscale up --exit-node=<exit-node-ip>

A subnet router is a device that advertises a local subnet to the tailnet. The other devices can reach the subnet through the router, which is the equivalent of a site-to-site VPN .

# On the subnet router
sudo tailscale up --advertise-routes=192.168.1.0/24

The --advertise-routes option requires the IP forwarding to be enabled on the device, and the routes must be approved in the admin console before the other devices can use them .

Complete Example Session

# ============================================
# PART 1: INSTALL TAILSCALE
# ============================================
curl -fsSL https://tailscale.com/install.sh | sh

# ============================================
# PART 2: AUTHENTICATE THE DEVICE
# ============================================
sudo tailscale up
# The command prints a URL; open it and log in with the identity provider

# ============================================
# PART 3: CHECK THE STATUS
# ============================================
tailscale status
# Output lists the devices and the connection types

# ============================================
# PART 4: CHECK THE CONNECTION TYPE TO A PEER
# ============================================
tailscale ping <peer-hostname>
# Output shows "direct" or "via DERP"

# ============================================
# PART 5: CHECK THE NAT TYPE
# ============================================
tailscale netcheck
# Output shows the NAT type and the DERP latency

# ============================================
# PART 6: ADVERTISE AN EXIT NODE
# ============================================
sudo tailscale up --advertise-exit-node

# ============================================
# PART 7: USE THE EXIT NODE
# ============================================
sudo tailscale up --exit-node=<exit-node-ip>

# ============================================
# PART 8: ADVERTISE A SUBNET
# ============================================
sudo tailscale up --advertise-routes=192.168.1.0/24

# ============================================
# PART 9: ENABLE MAGICDNS
# ============================================
# MagicDNS is enabled by default in the admin console
ping <device-hostname>
# The hostname resolves through MagicDNS

# ============================================
# PART 10: CHECK THE TAILNET IN THE ADMIN CONSOLE
# ============================================
# Open the admin console and review the devices, users, and policies

The ten parts demonstrate the Tailscale surface: the installation, the authentication, the status, the connection type, the NAT check, the exit node, the subnet router, the MagicDNS, and the admin console. The critical distinction is between Parts 4 and 5: the tailscale ping shows the connection type to a specific peer, and the tailscale netcheck shows the NAT type that determines it.

Quick Reference

Core Concepts

Concept	Meaning
Tailnet	The private network of devices and users
Coordination service	The control plane that distributes keys and policies
Data plane	The WireGuard tunnel on each device
Direct connection	Peer-to-peer WireGuard over UDP
DERP	Relayed connection through Tailscale’s servers
Peer relay	Relayed connection through another tailnet device
Exit node	A device that routes internet traffic
Subnet router	A device that exposes a local subnet

Tailscale IP Range

Range	Purpose
`100.64.0.0/10`	CGNAT range for tailnet addresses
`100.x.y.z`	The stable IP of each device

Commands

Command	Purpose
`tailscale up`	Authenticate and connect
`tailscale status`	Show the tailnet devices
`tailscale ping <peer>`	Check the connection type
`tailscale netcheck`	Show the NAT type and DERP latency
`tailscale up --advertise-exit-node`	Offer the device as an exit node
`tailscale up --exit-node=<ip>`	Route traffic through an exit node
`tailscale up --advertise-routes=<cidr>`	Advertise a subnet

Best Practices

✅ Do This:

# Use the identity provider for authentication
tailscale up                                                   # ✅

# Check the connection type before troubleshooting
tailscale ping <peer>                                          # ✅

# Use the exit node for the full tunnel
tailscale up --exit-node=<ip>                                  # ✅

# Advertise the subnet for the site-to-site access
tailscale up --advertise-routes=192.168.1.0/24                 # ✅

# Use MagicDNS for the hostnames
ping <device-hostname>                                         # ✅

# Review the admin console for the policies
# The default is deny-all                                       # ✅

❌ Don’t Do This:

# Assume every connection is direct
# The hard NAT forces the relayed connection                    # ❌

# Forget the IP forwarding on the subnet router
# The advertised routes do not work                             # ❌

# Use the exit node without the admin approval
# The exit node must be approved in the console                 # ❌

# Ignore the DERP latency
# The relayed connection is slower than the direct one          # ❌

# Expose the admin console without the MFA
# The admin console controls the entire tailnet                 # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Slow connection	The connection is relayed through DERP	Check `tailscale ping`; investigate the NAT
Subnet route not working	IP forwarding disabled or route not approved	Enable forwarding; approve in the console
Exit node not available	The exit node is not approved	Approve it in the admin console
Device not in the tailnet	Authentication not completed	Run `tailscale up` and log in
MagicDNS not resolving	MagicDNS disabled	Enable it in the DNS settings

Real-World Examples

1. Install Tailscale

curl -fsSL https://tailscale.com/install.sh | sh

2. Authenticate

sudo tailscale up

3. Check status

tailscale status

4. Check connection type

tailscale ping <peer>

5. Check NAT type

tailscale netcheck

6. Advertise exit node

sudo tailscale up --advertise-exit-node

7. Use exit node

sudo tailscale up --exit-node=<exit-node-ip>

8. Advertise subnet

sudo tailscale up --advertise-routes=192.168.1.0/24

9. Use MagicDNS

ping <device-hostname>

10. Check the tailnet

# Open the admin console at login.tailscale.com/admin

Visual

The Control Plane and the Data Plane

┌──────────────────────────────────────────────────────────────┐
│  THE COORDINATION SERVICE IS THE PHONE BOOK, NOT THE WIRE    │
│                                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Control plane: coordination service                    │  │
│  │ ├── stores the public keys                             │  │
│  │ ├── distributes the peer lists                         │  │
│  │ ├── enforces the access policies                       │  │
│  │ └── coordinates the NAT traversal                      │  │
│  └──────────────────────────┬─────────────────────────────┘  │
│                             │                                │
│                             │ peer lists and policies        │
│                             ▼                                │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Data plane: WireGuard tunnels                          │  │
│  │                                                        │  │
│  │ Device A (100.64.0.1) ◀────────▶ Device B (100.64.0.2) │  │
│  │                                                        │  │
│  │ The traffic is direct and end-to-end encrypted.        │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

The Connection Types

┌──────────────────────────────────────────────────────────────┐
│  DIRECT FIRST, THEN PEER RELAY, THEN DERP                    │
│                                                              │
│  Direct:                                                     │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Device A ◀──────────── UDP ────────────▶ Device B      │  │
│  │ Lowest latency, highest throughput                     │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  DERP:                                                       │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Device A ──▶ DERP server ──▶ Device B                  │  │
│  │ The relay forwards the encrypted packets               │  │
│  │ Higher latency, lower throughput                       │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  Peer relay:                                                 │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Device A ──▶ Device C ──▶ Device B                     │  │
│  │ Faster than DERP, slower than direct                   │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

The Exit Node and the Subnet Router

┌──────────────────────────────────────────────────────────────┐
│  TWO WAYS TO REACH THE NETWORK BEHIND THE TAILNET            │
│                                                              │
│  Exit node:                                                  │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Laptop ──▶ Exit node ──▶ Internet                      │  │
│  │ The exit node is the gateway for all the traffic       │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  Subnet router:                                              │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ Laptop ──▶ Subnet router ──▶ 192.168.1.0/24            │  │
│  │ The router exposes the local subnet to the tailnet     │  │
│  └────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Type	Mesh VPN built on WireGuard
Control plane	Coordination service
Data plane	WireGuard tunnels on each device
Tailnet IP range	`100.64.0.0/10`
Direct connection	Peer-to-peer WireGuard over UDP
DERP	Relayed connection through Tailscale’s servers
Peer relay	Relayed connection through a tailnet device
Exit node	Routes internet traffic
Subnet router	Exposes a local subnet
Authentication	Identity provider (SSO)
MagicDNS	Resolves the device hostnames

Key takeaways:

Tailscale is WireGuard plus the coordination layer. WireGuard provides the encrypted tunnel, and Tailscale provides the identity, the key distribution, the NAT traversal, and the access policies. The coordination service is the control plane, and the WireGuard tunnels are the data plane .
The coordination service is not in the data path. It distributes the public keys and the policies, and the devices communicate directly. If the coordination service goes offline, the established connections continue to work with the cached policies .
The connection type determines the performance. The direct connection is the fastest, the DERP relay is the fallback, and the peer relay is the middle ground. The tailscale ping and tailscale netcheck commands show the connection type and the NAT type .
Every device has a stable 100.x.y.z address. The address is assigned from the CGNAT range, and it does not change when the device moves between networks. The MagicDNS resolves the device hostnames to these addresses .
The exit node and the subnet router are the two ways to reach the network behind the tailnet. The exit node routes the internet traffic, and the subnet router exposes the local subnet. Both require the IP forwarding and the approval in the admin console .
The authentication is outsourced to the identity provider. Tailscale does not store the user passwords; it uses the OAuth2, OIDC, or SAML provider to authenticate the users. The access policies are written in terms of the identity, not the IP address .

Remember: Tailscale is the managed mesh that makes WireGuard practical at scale. The coordination service distributes the keys and the policies, and the WireGuard tunnels carry the data. The direct connection is the goal, the DERP relay is the fallback, and the peer relay is the compromise. The 100.x.y.z address is stable, and the MagicDNS resolves the hostnames. The exit node and the subnet router extend the tailnet to the internet and the local network. The result is a VPN that requires no port forwarding, no manual key exchange, and no firewall rules, and it authenticates the users through the identity provider they already use.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!