Mesh VPN with Tailscale

What you'll build and why

Tailscale builds a private mesh network -- a "tailnet" -- out of WireGuard tunnels between every device you add, but handles the parts that make raw WireGuard fiddly: key generation and distribution, NAT traversal (no port forwarding needed for most home networks), and a simple device list you manage from one place.

Don't build this if: you specifically don't want any third party involved in how your devices find and authenticate to each other, even though your actual traffic stays end-to-end encrypted between your own devices. That's a legitimate concern -- see Go further for Headscale, a self-hosted alternative to Tailscale's own coordination servers that keeps the same ease of use.

How it works

  Device A                Tailscale's coordination
(your phone)             servers ("control plane")
│                         │
│   "who else is on      │
│    my tailnet, and     │
│    how do I reach      │
│    them?"               │
└────────────►───────────┘
│
tells Device A how to reach
Device B directly
┌────────────◄───────────┘
│
▼
Direct WireGuard tunnel, Device A <-> Device B
(coordination servers are NOT in this path --
your actual traffic goes device-to-device)

The coordination servers help devices find and authenticate each other; they're not a relay for your actual data in the common case (a direct connection is established between devices once discovery happens -- this is the NAT traversal Tailscale handles for you). This is the trust model worth understanding: you're trusting Tailscale's coordination service with knowledge of your device list and enough to broker connections, not with your traffic content.

Before you start

Decision: Tailscale's own servers, or self-hosted Headscale? This guide uses Tailscale's own coordination servers -- the standard path, free for personal use, zero infrastructure to run yourself. If the third-party trust concern above matters to you, Headscale (Go further) is a drop-in open-source replacement for just the coordination layer, using the same Tailscale client software.

Steps

Step 1: Install Tailscale

Linux:

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

macOS/Windows/mobile: the native app from tailscale.com/download.

Step 2: Authenticate and join your tailnet

$ sudo tailscale up

This prints a login URL -- open it, sign in (Tailscale supports SSO via Google, GitHub, Microsoft, and others; the first login creates your tailnet, subsequent devices join the same one). Repeat Steps 1-2 on every device you want in the mesh.

Step 3: Confirm devices can reach each other

$ tailscale status

Shows every device on your tailnet and its Tailscale IP (a stable 100.x.y.z address that works regardless of the device's real network). From one device, ping another's Tailscale IP.

Step 4 (optional): Set up a subnet router to reach your whole LAN

If you want tailnet devices to reach things on your home network that don't themselves run Tailscale (a printer, a NAS), designate one device on that network as a subnet router:

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

Then approve the advertised route in the Tailscale admin console (Machines → [device] → Edit route settings) -- routes aren't active until approved, a deliberate safety check.

Step 5 (optional): Set up an exit node to route all traffic through home

$ sudo tailscale up --advertise-exit-node

Approve it in the admin console the same way as a subnet route. Other devices can then route all their traffic through this one (on the client: tailscale up --exit-node=<device-name>) -- useful on untrusted networks, at the cost of routing everything through your home connection's speed.

Verify it works

• tailscale status on each device shows every other device as connected
• A device can reach another device's Tailscale IP directly
• If configured: a subnet-routed device on your home LAN is reachable from a tailnet device that isn't itself on that LAN
• Failure test: disconnect the device acting as subnet router or exit node (if configured). Confirm other devices lose that specific capability (LAN access or exit routing) but keep direct tailnet-to-tailnet connectivity to each other -- confirms those are separate, optional capabilities, not load-bearing for the mesh itself

Secure it

• What's exposed: nothing new listens on your network by default -- Tailscale doesn't require inbound port forwarding for the common case. A subnet router or exit node, once approved, does extend what's reachable, so approve only routes you actually intend.
• Account security: since Tailscale authenticates via SSO, your tailnet's security is partly downstream of that identity provider's account security -- use MFA on whatever account you authenticate with.
• ACL tags: for anything beyond a single-person tailnet, Tailscale's ACL system lets you scope which devices can reach which -- worth setting up deliberately rather than leaving every device able to reach every other by default once you have more than a couple of devices or people involved.
• The failure that hurts most: approving a subnet route or exit node you didn't mean to, opening more access than intended. The step that prevents it: routes require explicit admin-console approval by design -- don't approve one without confirming you understand what it exposes.

Back it up and maintain it

What matters: there's no local state to back up in the way a self-hosted service has -- your tailnet's configuration lives in Tailscale's own account system. What you should keep track of yourself: which devices are authorized (periodically review and remove devices you no longer use, from the admin console).

Update cadence: the client auto-updates by default on most platforms; no manual version tracking needed.

Troubleshooting

Logs: tailscale status and tailscale ping <device> for connectivity; the admin console's device list for authorization state.

Undo

sudo tailscale down disconnects without removing the device from your tailnet; sudo tailscale logout deauthorizes it. Remove any device you're decommissioning from the admin console's device list directly.

Go further

• Remote Access with WireGuard -- the self-managed alternative this guide was compared against, if you want to run the whole thing yourself
• Headscale -- a self-hosted, open-source replacement for Tailscale's coordination servers, using the same Tailscale client -- removes the third-party trust concern while keeping the ease of use
• Tailscale's ACL system, once you have more than a couple of devices or people on your tailnet and want to scope access deliberately

Resources

Official documentation:

• Tailscale documentation
• Tailscale install guide

Source and releases:

• Tailscale client source

Community:

• Tailscale's own community forum
• r/Tailscale

Go deeper:

• Headscale -- the self-hosted coordination-server alternative mentioned in Go further

Related DaemonPress projects:

• Remote Access with WireGuard

Last verified: 2026-09-21, checked against official Tailscale documentation.