Tailscale Raspberry Pi: Complete Remote Access Guide

Q: Does Tailscale work if the Pi is behind a double NAT?

Yes. Double NAT prevents direct peer connections but Tailscale automatically falls back to a DERP relay. The connection works but with higher latency. Configuring port forwarding on the outer NAT or enabling UPnP improves direct connectivity.

Q: Should I use Tailscale or WireGuard for a home lab?

Tailscale for minimal configuration with a managed coordination service. WireGuard for no external dependencies and full control. Many homelab setups use both: Tailscale for casual remote access and WireGuard for always-on site-to-site links.

Q: Can I run Tailscale and WireGuard on the same Pi?

Yes. They use different network interfaces (tailscale0 and wg0) and do not conflict. Both can be active simultaneously.

Q: What happens if Tailscale's servers go down?

Existing connections persist. New connections and key re-negotiations require the coordination server and will fail until it recovers. In practice, Tailscale's coordination servers have high availability and downtime is rare.

Q: Is Tailscale suitable for a Pi running public-facing services?

No. Tailscale is for private network access between trusted devices. Public-facing services that need to be reachable by people without Tailscale need a reverse proxy with HTTPS instead.

Print 🖨 PDF 📄 eBook 📱

Tailscale Raspberry Pi gives you encrypted remote access to your Pi and its services from anywhere, with no port forwarding, no dynamic DNS, and no public exposure of any port. Tailscale builds a WireGuard-based mesh network between your devices, assigns each a stable private IP, and handles NAT traversal automatically. Your Pi sits behind a firewall with nothing open to the internet and is still reachable over SSH, web interfaces, and any other service from your phone or laptop anywhere in the world. This guide covers installation, authentication, subnet routing, exit nodes, MagicDNS, ACL configuration, Headscale as a self-hosted alternative, and troubleshooting.

Last tested: Raspberry Pi OS Bookworm Lite 64-bit | May 2, 2026 | Raspberry Pi 4 Model B (4GB) | Tailscale 1.78 | Headscale 0.23

Key Takeaways

Tailscale uses WireGuard for the data plane but adds a coordination server (Tailscale’s servers, or a self-hosted Headscale instance) that handles device authentication, key distribution, and ACLs. Unlike a self-hosted WireGuard setup, Tailscale requires an account with an identity provider. If Tailscale’s coordination servers go down, existing connections persist but new connections cannot be established until they recover.
For subnet routing to work, IP forwarding must be enabled on the Pi host and the route must be approved in the Tailscale admin console. Enabling subnet routing without approving it in the console does nothing. Both steps are required.
Tailscale is free for personal use up to 3 users and 100 devices. The free tier includes ACLs, MagicDNS, subnet routing, and exit nodes. Features like SSO integrations and priority support require a paid plan.

Tailscale Raspberry Pi: How It Differs from WireGuard

WireGuard is a VPN protocol. Tailscale is a product built on top of WireGuard. When you set up WireGuard manually, you generate key pairs, distribute public keys, configure allowed IPs, and manage the peer list yourself. When a new device joins, you update every existing peer configuration. Tailscale replaces all of that manual work with a coordination layer. Devices authenticate once through an identity provider, and Tailscale’s servers distribute the WireGuard keys and peer configurations automatically.

The trade-off is dependency. A self-hosted WireGuard setup has no external dependency after the initial configuration. Tailscale requires its coordination servers (or a self-hosted Headscale instance) to authenticate new connections and distribute key updates. For most homelab use cases this is not a meaningful limitation. Tailscale reliability is high and the coordination traffic is minimal.

Feature	Tailscale	WireGuard (self-hosted)
Setup complexity	Low: install and authenticate	Medium: key management, peer config
Peer management	Automatic via coordination server	Manual per-peer configuration
NAT traversal	Automatic (STUN + DERP relay fallback)	Manual (requires reachable endpoint)
Coordination dependency	Tailscale servers or Headscale	None after setup
ACL management	Web console or HuJSON file	iptables / nftables
Cost	Free tier available	Free, open source

For a full self-hosted WireGuard setup with site-to-site tunnels and manual key management, see WireGuard Raspberry Pi Site-to-Site VPN. Tailscale is the right choice when you want mesh networking without the manual configuration overhead. WireGuard is the right choice when you want no external dependencies and full control.

Installation and Authentication

Flash Raspberry Pi OS Bookworm Lite 64-bit using Raspberry Pi Imager. After first boot:

sudo apt update && sudo apt full-upgrade -y

Install Tailscale using the official script. This adds the Tailscale APT repository with the current keyring method and installs the latest stable release:

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

Authenticate the device to your tailnet:

sudo tailscale up

This outputs a URL. Open it on any device, log in with your identity provider (Google, GitHub, Microsoft, or email), and the Pi joins your tailnet. The tailscaled service starts automatically and is enabled at boot by the installer.

Expected result: tailscale status shows the Pi with a 100.x.x.x tailnet IP and status active. From any other device on your tailnet, ssh pi@<tailnet-ip> connects directly without any port forwarding or firewall changes.

# Check device status and tailnet IP
tailscale status

# Check connection quality to another device
tailscale ping <device-name>

# Check NAT traversal type and relay usage
tailscale netcheck

Tailscale Raspberry Pi tailnet diagram showing direct peer connections DERP relay fallback and coordination server

Key Features

Subnet routing

Subnet routing lets the Pi advertise your home LAN to your tailnet. Other tailnet devices can then reach your home network devices (NAS, printer, other Pis) directly without installing Tailscale on each one. This is the key feature for accessing a home lab remotely.

Enable IP forwarding on the Pi host first:

# Enable IP forwarding permanently
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Restart Tailscale advertising your LAN subnet:

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

Then approve the route in the Tailscale admin console at login.tailscale.com/admin/machines. Click the Pi entry, go to Edit route settings, and enable the advertised subnet. This second step is required. Advertising a route without approving it in the console has no effect.

On client devices, accept the subnet route:

sudo tailscale up --accept-routes

Expected result: From a remote device with Tailscale, you can reach your home network devices at their 192.168.1.x addresses through the Pi without those devices having Tailscale installed.

Exit node

An exit node routes all internet traffic from your remote device through the Pi. This means your remote device’s internet traffic appears to originate from your home IP. Enable exit node advertisement:

sudo tailscale up --advertise-exit-node

Approve the exit node in the admin console under the Pi’s machine settings, then use it from another device:

# Use the Pi as exit node (routes all traffic through it)
sudo tailscale up --exit-node=<pi-tailnet-ip> --exit-node-allow-lan-access

# Stop using the exit node
sudo tailscale up --exit-node=

MagicDNS

MagicDNS assigns DNS names to tailnet devices based on their machine name. With MagicDNS enabled, you can reach the Pi by hostname rather than tailnet IP. Enable it in the admin console under DNS > Enable MagicDNS. After enabling:

# Reach the Pi by name instead of 100.x.x.x
ssh pi@raspberrypi.your-tailnet-name.ts.net

# Or just the short hostname if using the same tailnet
ssh pi@raspberrypi

Access Control Lists

ACLs in the Tailscale admin console define which devices can reach which other devices and on which ports. The default policy allows all devices to reach all others. A more restrictive example that allows your laptop to SSH to the Pi but nothing else:

{
  "acls": [
    {
      "action": "accept",
      "src": ["tag:admin"],
      "dst": ["tag:server:22"]
    }
  ],
  "tagOwners": {
    "tag:admin": ["autogroup:owner"],
    "tag:server": ["autogroup:owner"]
  }
}

Tag the Pi as tag:server and your laptop as tag:admin in the machine settings. The ACL then allows SSH from admin devices to server devices. Any traffic not explicitly allowed is denied.

Security Hardening

Key expiry

By default, Tailscale device keys expire after 180 days. After expiry, the device must re-authenticate. For a headless Pi running services, key expiry causes an interruption. Disable expiry for specific devices in the admin console under the machine settings. Do this only for trusted, always-on infrastructure devices, not for user laptops or phones.

Auth keys for headless provisioning

For provisioning a Pi without interactive browser authentication, generate a reusable or one-time auth key in the admin console under Settings > Keys. Use it with:

sudo tailscale up --authkey=tskey-auth-xxxxxx

One-time keys expire after use. Reusable keys can be set with an expiry date and revoked from the console. Use one-time keys for provisioning new Pi installations and reusable keys only in automated deployment workflows where the key is stored securely.

SSH hardening alongside Tailscale

Tailscale does not replace SSH hardening. Even with Tailscale, if a device on your tailnet is compromised, it can attempt SSH. Disable password authentication and enforce key-based SSH:

# In /etc/ssh/sshd_config:
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

sudo systemctl reload sshd

Tailscale SSH is an optional feature that replaces the standard SSH daemon for tailnet connections. It uses Tailscale’s identity for authentication, eliminating the need for SSH keys or passwords for tailnet access. Enable it with:

sudo tailscale up --ssh

With Tailscale SSH enabled, you connect without any key management: ssh pi@raspberrypi authenticates using your Tailscale identity. Configure which tailnet users can SSH to which devices using the ACL policy.

Headscale: Self-Hosted Coordination Server

Headscale is an open-source, self-hosted implementation of the Tailscale coordination server. It provides the same device registration, key distribution, and ACL functions as Tailscale’s servers, but running on hardware you control. The Tailscale clients on your devices connect to your Headscale instance instead of controlplane.tailscale.com.

The trade-off is operational responsibility. Headscale is not officially supported by Tailscale and may lag behind the client’s expected API version. For a homelab that does not want any dependency on Tailscale’s servers or identity providers, it is the right choice. For most users the standard Tailscale service is simpler and more reliable.

A minimal Headscale install on a Pi or VPS:

# Download the latest Headscale release for arm64
wget https://github.com/juanfont/headscale/releases/latest/download/headscale_linux_arm64
sudo install -m 755 headscale_linux_arm64 /usr/local/bin/headscale

# Create config directory
sudo mkdir -p /etc/headscale /var/lib/headscale

# Generate a default config
headscale generate private-key | sudo tee /var/lib/headscale/private.key
chmod 600 /var/lib/headscale/private.key

Configure /etc/headscale/config.yaml with your server URL, then connect Tailscale clients using:

sudo tailscale up --login-server=https://your-headscale-server.domain.com

The full Headscale setup including user management, pre-auth keys, and HTTPS via Caddy is covered in the Headscale documentation.

Common Use Cases

Tailscale changes the practical question from “how do I expose this service securely?” to “is the device on my tailnet?” Several services on PidiyLab benefit directly from this:

Home Assistant: Access http://homeassistant:8123 from anywhere without exposing port 8123. No Nabu Casa subscription required for remote access. See Home Assistant Raspberry Pi 5.
Vaultwarden: The password manager never needs a public HTTPS endpoint. Access it at http://<pi-tailnet-ip>:8080 over the encrypted tailnet connection.
Grafana dashboards: Monitoring dashboards on the Pi are reachable at their LAN address through the tailnet without a reverse proxy or TLS configuration. See Grafana InfluxDB Raspberry Pi.
SSH to any Pi: All your Pis appear on the tailnet. No per-Pi port forwarding, no DDNS service, no firewall rules to maintain.

Troubleshooting

Device shows offline in admin console

sudo systemctl status tailscaled
journalctl -u tailscaled -n 30

If tailscaled is running but the device shows offline, the coordination server may be temporarily unreachable or the auth key has expired. Run tailscale status on the Pi to see the local view. If it shows NeedsLogin, run sudo tailscale up again to re-authenticate.

High latency or relay traffic

# Check whether connection is direct or using a DERP relay
tailscale ping <device-name>

# Check NAT type and available paths
tailscale netcheck

If tailscale ping shows via DERP rather than a direct connection, Tailscale could not punch through the NAT on one or both ends. This happens with symmetric NAT (common on some ISPs and mobile networks). The DERP relay adds latency but traffic is still encrypted end-to-end. Improving direct connectivity usually requires either UPnP enabled on the router or a static port mapping for UDP traffic.

Subnet routes not working

# Confirm IP forwarding is active
sysctl net.ipv4.ip_forward

# Confirm Tailscale is advertising the route
tailscale status --json | grep -i route

# Confirm the route is approved in the admin console
# login.tailscale.com/admin/machines > Edit route settings

Both steps are required: IP forwarding enabled on the host, and the route approved in the console. Missing either one means the route silently does not work. Also confirm client devices have run tailscale up --accept-routes.

MagicDNS not resolving

tailscale status | grep dns
cat /etc/resolv.conf

MagicDNS works by pushing a DNS nameserver to each Tailscale client. If it conflicts with a local DNS resolver like Pi-hole or dnsmasq, resolution may fail. Check /etc/resolv.conf to confirm the Tailscale DNS resolver is present. If Pi-hole is running on the same device, configure Pi-hole to forward Tailscale domain queries to the Tailscale DNS resolver rather than blocking them.

FAQ

Does Tailscale work if the Pi is behind a double NAT?

Yes. Double NAT (common with ISP-provided modems and a separate router) prevents direct peer connections but Tailscale automatically falls back to a DERP relay for the data path. The connection works but with higher latency than a direct path. If direct connections matter, configure port forwarding on the outer NAT to pass UDP traffic to the Pi, or enable UPnP on both routers.

Should I use Tailscale or WireGuard for a home lab?

Tailscale if you want minimal configuration and are comfortable with a managed coordination service. WireGuard if you want no external dependencies, full control, or need site-to-site VPN tunnels between fixed endpoints. Many homelab setups use both: Tailscale for casual remote access to any device, and WireGuard for specific always-on site-to-site links. See WireGuard Raspberry Pi Site-to-Site VPN for the WireGuard setup.

Can I run Tailscale and WireGuard on the same Pi?

Yes. They use different network interfaces and do not conflict. Tailscale creates a tailscale0 interface and WireGuard creates a wg0 interface. Both can be active simultaneously. Route traffic appropriately using routing rules if both are providing subnet access to overlapping address ranges.

What happens if Tailscale’s servers go down?

Existing connections between devices persist. The WireGuard tunnels remain active. New connections and key re-negotiations require the coordination server and will fail until it recovers. Device expiry re-authentication also requires the coordination server. In practice, Tailscale’s coordination servers have high availability and downtime is rare and brief.

Is Tailscale suitable for a Pi running public-facing services?

Tailscale is for private network access, not public-facing services. If a service needs to be reachable by people who do not have Tailscale on your tailnet (a public website, a public API, or a publicly accessible camera), you need a reverse proxy with HTTPS, not Tailscale. Use Caddy for that. See Caddy Reverse Proxy Raspberry Pi. Use Tailscale for services that only need to be reachable by you and trusted users.

References

About the Author

Chuck Wilson has been programming and building with computers since the Tandy 1000 era. His professional background includes CAD drafting, manufacturing line programming, and custom computer design. He runs PidiyLab in retirement, documenting Raspberry Pi and homelab projects that he actually deploys and maintains on real hardware. Every article on this site reflects hands-on testing on specific hardware and OS versions, not theoretical walkthroughs.

Last tested hardware: Raspberry Pi 4 Model B (4GB). Last tested OS: Raspberry Pi OS Bookworm Lite 64-bit. Tailscale 1.78, Headscale 0.23.

Was this helpful?

Yes

Thanks for your feedback!