Tailscale Operations Manual
On this page
Verify login, peer path, subnet routes and access policy separately. Reaching a gateway in the tailnet does not establish reachability of a service behind it. DERP relay is a functioning path, not itself a failure.
| Task | Start here |
|---|---|
| Peer unreachable / slow | Identity and actual path |
| Reach a private subnet | Advertise, approve, accept |
| Use an exit node | Default exit and LAN |
Inspect the client state
Verify identity and online state first
# Inspect client and daemon versions
Check local help for options and record versions when diagnosing platform differences.
# Inspect local and peer identities and connection state
Find PEER_NAME here. Resolve logged-out state before advertising routes. Use status --json separately for machine-readable data.
# Read this node’s Tailscale IPv4 address
This is not its LAN address; the service listener must cover it or an appropriate wildcard.
Separate path probes from application checks
# Probe the Tailscale path to the verified peer
Observe direct/relay and RTT; initial relay may transition to direct. Success still requires application-port testing.
# Inspect local UDP, NAT, and DERP reachability
This diagnoses the local network, not a peer’s throughput; correlate actual status/ping paths.
# Read recent service logs on the Linux daemon host
Use platform diagnostics elsewhere. Correlate login, route settings, and network transitions rather than merely restarting.
Login, disconnect, and logout are separate actions
# Start login or activation when required
Complete authentication as prompted. Preserve existing non-default settings instead of adding --reset. Choose down to disconnect; logout only to remove login identity.
Replace PEER_NAME and inspect direct/relay paths and changes. netcheck probes local UDP/NAT/DERP, not the destination application. Test the peer IP and actual port before isolating MagicDNS. System getent and querying 100.100.100.100 follow different paths. wg show is not a general diagnostic for userspace Tailscale WireGuard.
| Operation | Effect |
|---|---|
| tailscale up | Authenticate/enable; consider existing non-default options |
| tailscale set ... | Change selected preferences without restating all options |
| tailscale down | Disconnect while retaining identity |
| tailscale logout | Log out locally; not the same as deleting the admin-console device |
Route installation and policy permission are independent
Router: verify forwarding and advertise subnets
# Read IPv4 forwarding on the subnet router
1 means enabled. Inspect IPv6 forwarding separately; record previous values before changing. The following example is IPv4 only.
# Temporarily enable planned IPv4 forwarding on the router
Persist the same key in a dedicated /etc/sysctl.d/ file and load that file with sysctl -p, avoiding unrelated settings. Forwarding is not access authorization.
# Advertise a subnet reachable from this router
Replace the documentation subnet. This replaces the advertised list; include all intended CIDRs separated by commas. Approve routes or verify autoApprovers and access policy.
Linux client: accept and verify
# Accept routes on the Linux client that needs the subnet
Run this on the client, not automatically on the router. Verify ip route get TARGET_IP and an application request to a real subnet host.
To undo, restore the prior advertised list and client accept-routes value; clear/disable only if no other routes were needed. Restore forwarding and its persistent file to prior values too.
Use a subnet actually reachable by the router. advertise-routes replaces that preference’s list, so retain other required entries. Persist forwarding for the used IP families. Approval/autoApprovers, client acceptance and policy are separate gates; a present route may still be filtered. Linux normally needs explicit route acceptance.
Default subnet SNAT makes the destination see the router as source. Establish return routes before disabling it. HA routers should not blindly accept the same routes they advertise. Verify client route, router forwarding, destination listener, return packets and policy.
Exit nodes change the default internet path
Advertise and approve the exit node first
# Advertise exit-node capability on the prepared router
Check required IPv4/IPv6 forwarding first, approve exit use in the admin console, and verify user policy.
Select the exit on the client, then test requests
# Select an approved exit node on the client
Obtain the name from status/admin records. Verify egress with a trusted IP-check service and application requests, plus DNS. Evaluate local LAN access separately.
# Deselect the exit node when no longer needed
This is later cleanup, not an immediate sequel. Recheck egress/DNS; it does not stop the remote exit node.
Verify egress and DNS with a real external request. Assess exit-node-allow-lan-access separately for the client LAN; it does not grant tailnet ACL access. hosts aliases only name addresses; grants/ACL determine permission. Validate policy tests and real ports, not just online status.
Diagnose DERP using path evidence
For a slow relay path, correlate RTT, throughput, loss, CPU and network constraints before changing NAT. Self-hosted DERP hostname, TLS, ports and map are deployment-specific, not a fixed 8443 convention. Inspect tailscale debug --help for versioned commands.
Tailscale CLI · Route injection · Subnet routers · Exit nodes