Private Networking Without the Headaches
Setting up a VPN the traditional way means certificates, firewall rules, port forwarding, and an afternoon of troubleshooting before a single device connects. Tailscale takes a completely different approach – it builds a mesh network between your devices using WireGuard under the hood, handles authentication through your existing identity provider, and gets a new device online in roughly three minutes. No server to maintain, no public IP required, no certificate authority to babysit.
The result is a private network that behaves like all your devices are on the same local network, whether they are sitting in your home lab, a coffee shop, or a cloud provider’s data center. This guide walks through installing Tailscale, connecting your first devices, and configuring the features that make it genuinely useful for self-hosted setups.
Creating an Account and Installing the Client
Start at tailscale.com and sign up using a Google, Microsoft, GitHub, or Apple account. Tailscale uses these as identity providers rather than managing its own username and password system, which eliminates one more credential to protect. The free plan supports up to 100 devices and three users, which covers most personal and small homelab setups without any payment information required.
Once your account exists, install the client on each device you want to connect. On Debian and Ubuntu-based Linux systems, add the Tailscale repository and install through apt:
curl -fsSL https://tailscale.com/install.sh | sh
After installation, run sudo tailscale up and follow the authentication URL it prints. The command opens a browser-based login flow tied to the identity provider you chose at signup. After authenticating, the device appears in the Tailscale admin console at login.tailscale.com/admin/machines. Repeat this process on every machine – Windows, macOS, iOS, Android, and Linux all have native clients, and the installation is identical in structure across platforms.
Understanding the Network Tailscale Builds
Every device on your Tailscale network gets a stable IP address in the 100.x.x.x range – part of the Carrier-Grade NAT space that does not conflict with typical home or office networks. These addresses are persistent, so a server that gets a 100.64.0.5 address keeps that address even if its underlying network interface changes. This makes it practical to hardcode Tailscale IPs in configuration files without worrying about them shifting.
Tailscale also assigns each device a DNS name under the tailnet’s domain – something like myserver.tail1234.ts.net. With MagicDNS enabled in the admin console, devices on the network can reach each other by hostname rather than IP. Enable it under DNS settings in the admin panel, and from that point forward you can SSH into a machine using just its name. For anyone running multiple self-hosted services, this alone removes a significant source of friction.
Subnet Routing and Exit Nodes
Tailscale’s real power for homelab users comes from subnet routing. By default, Tailscale only connects the specific devices where its client is installed. Subnet routing lets one Tailscale node advertise an entire local network segment, making all devices on that subnet reachable without installing Tailscale on each one. A NAS, a printer, a smart home hub, or an unmanaged switch can all become accessible from anywhere through a single router running Tailscale.
To enable subnet routing on a Linux machine, run: sudo tailscale up –advertise-routes=192.168.1.0/24, replacing the subnet with your actual local range. Then approve the route in the admin console under the machine’s settings – Tailscale requires explicit approval to prevent accidental route leaks. On client machines, enable subnet route acceptance either globally in the admin console or per-device using tailscale up –accept-routes.
Exit nodes work the other direction – they route all internet traffic from a device through another Tailscale node rather than the device’s local connection. This is useful when using untrusted networks and you want traffic to exit from your home connection instead. Advertise a node as an exit node with sudo tailscale up –advertise-exit-node, approve it in the admin console, and then select it from the client app or with tailscale up –exit-node=100.x.x.x. Unlike subnet routing, you probably do not want exit node traffic enabled by default – it routes everything, which adds latency and consumes your home upload bandwidth.
Access controls in Tailscale use a declarative ACL format called HuJSON, edited directly in the admin console under the “Access Controls” tab. The default policy allows all devices on a tailnet to reach each other, which is fine for personal use. For setups with multiple users or devices you want to segment – say, keeping IoT devices from reaching your main workstation – you define rules specifying which sources can reach which destinations on which ports. The syntax is straightforward: a source tag, a destination tag, and a list of allowed ports. Tags get assigned to machines either manually in the console or automatically through auth keys configured to apply specific tags at enrollment time.
Tailscale SSH and Key Management
One feature that often goes overlooked is Tailscale SSH, which replaces traditional SSH key management with Tailscale’s identity-based authentication. Enable it by running sudo tailscale up –ssh on the target machine. From that point, any device on your tailnet authenticated as the correct user can SSH into that machine without needing a pre-shared key in an authorized_keys file. The access control rules in your tailnet policy govern who can connect, and all session activity can be logged.
For automated deployments, Tailscale provides auth keys that allow devices to join a tailnet without interactive browser authentication. Generate them in the admin console under Settings – Auth Keys. Ephemeral keys are ideal for containers and temporary workloads because the devices they create automatically disappear from your machine list when they disconnect. Reusable keys work for persistent machines being provisioned through scripts or configuration management tools. Combining auth keys with pre-applied tags lets you build a tailnet where newly enrolled servers automatically inherit the right ACL policies the moment they come online.
The trade-off worth understanding before committing: Tailscale’s coordination server, which handles device discovery and key exchange, is operated by Tailscale Inc. The actual traffic between your devices travels peer-to-peer over WireGuard and never passes through Tailscale’s infrastructure – but the control plane does. For organizations where that dependency is unacceptable, Headscale is an open-source reimplementation of the Tailscale coordination server that you can self-host. It is not officially supported by Tailscale and lags behind the official feature set, but it exists and works. Most personal users will never have reason to care about this distinction, but if you are running self-hosted infrastructure and already have a monitoring stack watching your drives, it is the kind of architectural detail worth knowing before you depend on the service.
