Tailscale Operations Manual

12 min read
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.

TaskStart here
Peer unreachable / slowIdentity and actual path
Reach a private subnetAdvertise, approve, accept
Use an exit nodeDefault exit and LAN

Inspect the client state

Verify identity and online state first

# Inspect client and daemon versions
tailscale version

Check local help for options and record versions when diagnosing platform differences.

# Inspect local and peer identities and connection state
tailscale status

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
tailscale ip -4

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
tailscale ping PEER_NAME

Observe direct/relay and RTT; initial relay may transition to direct. Success still requires application-port testing.

# Inspect local UDP, NAT, and DERP reachability
tailscale netcheck

This diagnoses the local network, not a peer’s throughput; correlate actual status/ping paths.

# Read recent service logs on the Linux daemon host
journalctl -u tailscaled -b -n 100 --no-pager

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
sudo tailscale up

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.

OperationEffect
tailscale upAuthenticate/enable; consider existing non-default options
tailscale set ...Change selected preferences without restating all options
tailscale downDisconnect while retaining identity
tailscale logoutLog out locally; not the same as deleting the admin-console device

Route installation and policy permission are independent

Subnet-route prerequisites Router advertises CIDR Admin approves Client accepts routes Policy + forwarding + return

Router: verify forwarding and advertise subnets

# Read IPv4 forwarding on the subnet router
sysctl net.ipv4.ip_forward

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
sudo sysctl -w net.ipv4.ip_forward=1

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
sudo tailscale set --advertise-routes=192.0.2.0/24

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
sudo tailscale set --accept-routes=true

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 exit-node capability on the prepared router
sudo tailscale set --advertise-exit-node

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
sudo tailscale set --exit-node=EXIT_NODE_NAME

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
sudo tailscale set --exit-node=''

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