Remote access VPNs built on shared secrets and open UDP ports are a liability most security teams can no longer justify. Tailscale 1.102.5, released in September 2026 according to the project’s GitHub release notes, has become the default answer for engineering teams that want a mesh VPN without the router config, the certificate authority, or the exposed attack surface of a traditional remote-access gateway. That same month Tailscale also moved new tailnets onto seat-based billing, a change worth knowing about before you provision accounts below. This tutorial walks through a complete zero-trust Tailscale deployment: install, identity-aware SSH, subnet routing, exit nodes, and access control lists, built on the WireGuard protocol underneath.
By the end you will have a working tailnet connecting a home lab, a cloud VM, and a laptop, with device-level authorization instead of a shared PSK. Every command below has been tested against the current Tailscale release and the equivalent Android client build, both now at 1.102.5, with the lineage tracing back through the v1.96.4 product update Tailscale shipped in March 2026, so the steps hold up even if your fleet hasn’t updated past that release yet.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is Tailscale and Why Zero Trust Changes the VPN Model
Tailscale is a zero-configuration mesh VPN service that connects devices into a private network called a tailnet, using the WireGuard protocol for the actual encrypted tunnels. The difference between Tailscale and a classic VPN concentrator is architectural, not cosmetic. A traditional remote-access VPN puts one box at the network edge, opens a port for it, and trusts anyone who authenticates through it to reach whatever is behind that box. Tailscale instead builds a full mesh: every device talks directly to every other device it is authorized to reach, and that authorization is evaluated per-connection rather than once at login.
That per-connection model is what zero trust actually means in practice, and it lines up with the framework NIST laid out in Special Publication 800-207: no implicit trust based on network location, continuous verification, and access scoped to the specific resource rather than the whole subnet. A Tailscale VPN setup treats every connection as untrusted until it is explicitly allowed, which means a compromised laptop cannot pivot into a database server just because both machines happen to be on the same tailnet unless an access control list says otherwise.
The tradeoff most teams accept without realizing it: classic VPNs are simpler to reason about in a whiteboard diagram, but they fail badly under lateral movement. Tailscale’s mesh model is more moving parts up front, and it is exactly those moving parts this tutorial sets up correctly, step by step.
There is also an operational argument that gets less attention than the security one. A traditional site-to-site VPN concentrator is a single point of failure: if that box goes down, every remote user loses access simultaneously. Because Tailscale builds direct peer-to-peer tunnels between devices rather than routing everything through one gateway, losing any single non-router node only affects connections to that specific device. The mesh degrades gracefully instead of failing all at once, which matters more than it sounds once a team has grown past a handful of machines.
Tailscale vs Raw WireGuard vs Traditional VPN Concentrators
Before diving into the install steps, it helps to see where Tailscale actually sits relative to the two alternatives most teams are coming from: hand-rolled WireGuard configs, and a legacy IPsec or OpenVPN concentrator. Each has a real place, and the right choice depends less on which is “best” and more on who has to maintain it six months from now.
| Factor | Tailscale | Raw WireGuard | OpenVPN / IPsec Concentrator |
|---|---|---|---|
| Underlying protocol | WireGuard | WireGuard | TLS or IKEv2/IPsec |
| Config management | Automatic, key distribution handled centrally | Manual, per-peer config files | Manual, per-user certificates or PSKs |
| NAT traversal | Automatic, DERP relay fallback | Manual port forwarding required | Requires a public-facing gateway IP |
| Access control granularity | Per-device, per-tag, ACL policy file | Per-peer, manually maintained | Typically network-wide once authenticated |
| Identity integration | Delegated to OIDC/SSO provider | None built in | Varies, often a separate local user database |
| Setup time for a 10-device mesh | Under 30 minutes | 2-4 hours of manual config | Half a day including certificate setup |
| Best fit | Distributed teams, CGNAT environments, non-technical users | Small, static, technical-only deployments | Large enterprises with existing PKI investment |
The practical takeaway: raw WireGuard is still the leaner option for two or three servers that never change, since it has no external dependency on Tailscale’s coordination servers. Once a deployment grows past that, needs to onboard non-technical users, or has to support devices behind carrier-grade NAT that can’t accept inbound connections, the manual overhead of raw WireGuard starts costing more engineering time than a Tailscale subscription would.
Prerequisites and Version Requirements
Confirm each of these before starting. Version mismatches are the single most common cause of Tailscale setup failures reported in community forums.
| Requirement | Minimum / Target Version | Notes |
|---|---|---|
| Tailscale client (Linux/macOS/Windows) | 1.102.4 (Sept 10, 2026) | Latest tagged GitHub release as of this writing |
| Tailscale Android client | 1.102.4 (Sept 11, 2026) | Synced release cadence with desktop/server line |
| Operating system | Ubuntu 22.04+/24.04, Debian 12, macOS 14+, Windows 11, or Arch Linux | systemd required for the exit-node steps below |
| Root or sudo access | Required | Needed for sysctl, systemd units, and the install script |
| Tailscale account | Free tier or higher | Free tier supports up to 6 users and unlimited devices as of 2026 |
| Open outbound UDP | Not strictly required | Tailscale falls back to DERP relays if UDP is blocked, at a latency cost |
| Disk space | Under 50MB | Tailscale binaries are lightweight compared to full VPN suites |
You do not need a static public IP, a firewall rule opening an inbound port, or a certificate authority. That absence of inbound exposure is the main security argument for this setup over a self-hosted OpenVPN or IPsec gateway.
Step 1: Create a Tailscale Account and Understand the Admin Console
Sign up at tailscale.com using an identity provider you already trust for your organization: Google Workspace, Microsoft Entra ID, GitHub, or a generic OIDC provider. This choice matters more than it looks. Tailscale does not run its own separate user directory by default, it delegates authentication to whichever identity provider you pick, which means offboarding an employee from that provider also removes their tailnet access automatically.
Once signed in, open the admin console. Three tabs matter for this tutorial: Machines (every device currently on the tailnet), Access Controls (the ACL policy file, in HuJSON format), and DNS (MagicDNS settings and any custom nameservers). Leave these open in a browser tab, since several steps below require flipping settings here after running a command on a device.
Before adding any devices, decide on a tagging convention. A useful starting point most teams converge on independently: tag:home for personal infrastructure, tag:prod-* for anything customer-facing, tag:dev-* for staging and test environments, and tag:ci-* for automated runners. Deciding this up front avoids a painful retroactive tagging exercise once fifteen devices are already on the tailnet with inconsistent names.
Step 2: Install Tailscale on Linux
On any Debian, Ubuntu, Fedora, or Arch-based system, the official install script detects the distribution and configures the correct package repository automatically.
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale upThe second command prints a URL. Open it in a browser, authenticate against your identity provider, and the device appears in the admin console’s Machines list within a few seconds. On Arch Linux specifically, the tailscale package ships a systemd unit that is not enabled by default, so run this immediately after install:
sudo systemctl enable --now tailscaled.serviceSkipping that step is a common pitfall on Arch: the connection works during the current session but drops after the next reboot because the daemon never starts automatically.
Step 3: Verify the Tailnet Connection
Confirm the device picked up a tailnet address and can see its peers.
tailscale ip -4
tailscale statusThe IP returned should start with 100 (for example, 100.12.34.56). Every device on every tailnet gets an address from that same 100.64.0.0/10 CGNAT range, which is reserved and never routes on the public internet, so there is no collision risk with your existing LAN. Example output:
$ tailscale status
100.64.11.2 home-server [email protected] linux -
100.64.22.9 macbook-pro [email protected] macOS active; direct 203.0.113.4:41641
100.64.33.4 cloud-vm-nyc [email protected] linux idle, tx 1204 rx 998“direct” in the status line means the two devices found a peer-to-peer path (NAT traversal succeeded). If you instead see “relay” next to a device, traffic is bouncing through one of Tailscale’s DERP relay servers, which works but adds latency, typically 20-80ms depending on relay proximity.
Step 4: Install Tailscale on macOS, Windows, and Mobile
macOS and Windows users can install from the Mac App Store or the standalone .exe/.pkg from the Tailscale download page, or use a package manager:
# macOS via Homebrew
brew install tailscale
# Windows via winget
winget install tailscale.tailscaleOn Android and iOS, install from the Play Store or App Store (Android client currently at 1.102.4), sign in with the same identity provider, and the device joins the tailnet the same way a desktop client would. There is no separate mobile configuration profile to build, which is a meaningful difference from most enterprise MDM-managed VPN clients.
Step 5: Set Up MagicDNS for Human-Readable Hostnames
Typing 100.64.33.4 to reach a server gets old fast. MagicDNS assigns every device a stable hostname under your tailnet’s .ts.net domain. Enable it from the admin console’s DNS tab, then any device on the tailnet can resolve peers by name:
ping cloud-vm-nyc.tailxxxxx.ts.net
ssh [email protected]If you run a reverse proxy in front of a self-hosted app (Jellyfin, a Grafana dashboard, an internal admin panel) that also lives on the tailnet, add the proxy’s own Tailscale IP to that application’s “known proxies” or trusted-proxy allowlist. Skipping this is a subtle pitfall: the app will work but will log every request as coming from the proxy’s IP instead of the real client, breaking rate limiting and audit logs.
Step 6: Enable Tailscale SSH for Identity-Aware Remote Access
Tailscale SSH replaces static SSH keys with identity-based authorization enforced through the same ACL policy that governs network access. Enable it on any Linux machine:
sudo tailscale set --sshConnect using either the Tailscale-aware client or a regular SSH client pointed at the MagicDNS name:
tailscale ssh user@home-server
# or, using regular OpenSSH against the MagicDNS name
ssh [email protected]The practical win here is that you stop distributing and rotating SSH private keys across a fleet. Access is granted or revoked in the ACL file, and every session is attributable to the authenticated identity rather than “whoever holds this key.” Tailscale also supports SSH session recording for audit purposes, documented in the official Tailscale SSH audit logging guide, which matters for teams under SOC 2 or similar compliance obligations.
Step 7: Configure Subnet Routing to Reach Non-Tailscale Devices
Most home labs and office networks have devices that will never run the Tailscale client directly: printers, NAS boxes, IoT sensors, legacy servers. Subnet routing lets one tailnet node act as a gateway into an entire local network. First, enable IP forwarding on the machine that will act as the router.
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -pThen advertise the subnet you want to expose:
sudo tailscale up --advertise-routes=192.168.1.0/24,10.0.0.0/8Advertising a route is not the same as approving it. Go to the admin console’s Machines tab, find the device, and explicitly approve the advertised subnet under its route settings. This split between “advertise” and “approve” is intentional: it means a compromised or misconfigured device cannot silently expose an entire internal network just by running one command, an administrator with console access has to sign off. On client devices that need to reach that subnet, run:
sudo tailscale set --accept-routesStep 8: Configure an Exit Node for Full-Tunnel Traffic
An exit node routes all of a client’s internet traffic, not just tailnet traffic, through another device on the tailnet. This is the closest Tailscale gets to a traditional “connect to VPN, browse from a different location” experience, useful for accessing geo-restricted resources or hardening a laptop’s traffic on untrusted public Wi-Fi.
On the machine that will serve as the exit node (a cloud VM with a reliable connection works well):
sudo tailscale up --advertise-exit-nodeAs with subnet routes, this only advertises the capability. Approve it in the admin console under that device’s settings before it becomes usable. Then on the client that wants to route through it:
tailscale up --exit-node=100.64.33.4 --exit-node-allow-lan-accessThe --exit-node-allow-lan-access flag matters if the client also needs to reach printers or other devices on its own local network while the exit node is active; without it, all local traffic gets forced through the tunnel too, which breaks LAN-only devices like smart TVs or local network scanners.
Step 9: Write Access Control List Rules for Least-Privilege Access
The ACL policy file is where zero trust actually gets enforced. By default, a fresh tailnet allows every device to reach every other device, which is fine for a personal setup but wrong for anything with more than one user. Open the Access Controls tab in the admin console and edit the HuJSON policy:
{
"tagOwners": {
"tag:prod-db": ["group:platform-team"],
"tag:dev": ["autogroup:member"]
},
"acls": [
{
"action": "accept",
"src": ["group:platform-team"],
"dst": ["tag:prod-db:5432"]
},
{
"action": "accept",
"src": ["autogroup:member"],
"dst": ["tag:dev:*"]
}
]
}This example grants the platform team SSH-adjacent access to a tagged production database on port 5432 only, while every authenticated member can reach anything tagged dev on any port. Tag a device from the CLI with sudo tailscale up --advertise-tags=tag:prod-db, then approve the tag assignment in the console the same way you approved routes and exit nodes. Test rules with the built-in ACL simulator in the admin console before saving, since a syntax error in this file can lock every device out simultaneously.
Step 10: Harden the Deployment With Key Expiry and Device Approval
Two settings in the admin console close common gaps left over from the default configuration. First, under Machines settings, disable “key expiry disabled” exceptions except for infrastructure that genuinely cannot re-authenticate interactively (a headless server, for instance). Tailscale node keys expire every 180 days by default; leaving that expiry active means a stolen or forgotten device silently loses tailnet access rather than staying connected indefinitely.
Second, enable “require device approval” under the same settings tab. With this on, a new device authenticating against your identity provider still cannot join the tailnet until an admin manually approves it in the console. This closes the gap where a compromised or shared identity-provider credential alone would be enough to add a rogue device.
Step 11: Set Up Headless Servers With Auth Keys
Cloud VMs and CI runners cannot open a browser to authenticate interactively. Generate a reusable or single-use auth key from the admin console’s Keys tab, then bring the machine up non-interactively:
sudo tailscale up --authkey=tskey-auth-xxxxxxxxxxxx --advertise-tags=tag:ci-runnerSet auth keys to expire, and prefer single-use over reusable keys for anything provisioned by automation, since a reusable key that leaks into a build log or a public repository can be used to enroll arbitrary rogue devices until someone notices and revokes it.
Step 12: Migrate From an Existing WireGuard or pfSense Setup
Teams already running WireGuard directly, including through pfSense, generally do not need to rip it out on day one. The common pattern documented across current network-engineering guides is a phased migration: install Tailscale alongside the existing WireGuard configuration using the same curl install script from Step 2, run both in parallel while validating that every user and service can reach what it needs over the tailnet, and only then retire the manually managed WireGuard peers and config files.
Raw WireGuard on pfSense is still the better fit when you control the network edge and can open a UDP port directly, since it avoids the DERP relay dependency entirely. Tailscale earns its keep specifically when devices sit behind CGNAT, when non-technical users would otherwise need to edit a WireGuard config file by hand, or when you need per-user, per-device access policy rather than a flat point-to-point tunnel.
Step 13: Expose a Local Service Publicly With Tailscale Funnel
Sometimes the goal is the opposite of a private tailnet: sharing one specific service with someone who is not on your tailnet at all, without deploying a separate cloud server or paying for a reverse proxy service. Tailscale Funnel solves that narrow case by exposing a single port on a single device to the public internet over HTTPS, using a Tailscale-managed certificate, while everything else on that device and the rest of the tailnet stays private.
sudo tailscale serve https / http://localhost:8080
sudo tailscale funnel 443 onThe first command tells Tailscale to reverse-proxy HTTPS traffic on that device to a local service running on port 8080. The second turns on Funnel, which is what actually makes that endpoint reachable from outside the tailnet, at a public URL under your tailnet’s .ts.net domain. Funnel has to be explicitly enabled per-node in the admin console’s Funnel settings before the CLI command will take effect, following the same advertise-then-approve pattern used for subnet routes and exit nodes. This is useful for quickly sharing a demo, a webhook receiver, or a small internal tool with an external collaborator, but it is not a substitute for a real CDN or WAF in front of a production service handling meaningful traffic volume or hostile input.
Monitoring, Logging, and Compliance Reporting on a Tailnet
A tailnet that nobody monitors is a tailnet where a compromised device can sit quietly for months. Tailscale exposes two categories of log data worth wiring into an existing monitoring stack: network flow logs, showing which devices talked to which other devices and when, and configuration audit logs, showing every change made to the ACL policy, tags, or admin settings.
Both are available through the admin console under Logs, and both can be streamed out via the Tailscale API rather than checked manually. A minimal but genuinely useful setup: a scheduled job that pulls the configuration audit log every hour and forwards it to whatever log aggregator the team already runs (Splunk, Datadog, an ELK stack, or even a plain S3 bucket with lifecycle rules), paired with an alert on any change to the ACL file outside of business hours. That single alert catches both accidental misconfigurations and the early stage of a credential-based intrusion, since an attacker who gains admin console access will often try to loosen ACL rules before doing anything else.
For teams under a compliance framework that requires session-level accountability, combine Tailscale SSH’s session recording (enabled per-node the same way SSH itself is enabled) with a retention policy that matches whatever your auditor expects, commonly 90 days to one year depending on the framework. Tailscale stores recordings in whatever destination you configure, typically an S3-compatible bucket, it does not host them indefinitely on its own infrastructure.
Tailscale Pricing Tiers for Growing Teams
Cost is rarely the deciding factor for a personal setup, but it becomes relevant fast once a company-wide rollout is on the table, especially since Tailscale moved new tailnets to seat-based billing in September 2026 and bundled unlimited devices per user into its paid plans the same month. Current published tiers break down roughly as follows.
| Plan | Users / Devices | Key Features |
|---|---|---|
| Personal / Free | Up to 3 users, 100 devices | Core mesh VPN, MagicDNS, basic ACLs |
| Personal Pro | 1 user, higher device cap | Extended device limit for power users and home labs |
| Starter (paid, per-user) | Small teams | SSO integration, device approval, key expiry controls |
| Premium (paid, per-user) | Growing teams | Audit logs, session recording, advanced ACL tagging |
| Enterprise (custom pricing) | Large organizations | SCIM provisioning, dedicated support, custom SLAs |
As of late 2025, Tailscale’s published rate card put Free at $0 for up to 6 users, Standard at $8 per user per month, and Premium at $18 per user per month, and by September 2026 the paid tiers also included unlimited devices per seat, so it is still worth checking the current rate card on Tailscale’s own pricing page before budgeting a rollout, since per-seat terms can shift again. The practical guidance that does not change: the free tier is genuinely sufficient for the three-node lab built in this tutorial, and most teams only hit a wall once they need SSO enforcement or audit logging for a compliance requirement, at which point Standard or Premium becomes necessary rather than optional.
Common Pitfalls When Setting Up Tailscale
These are the mistakes that show up most often in support threads and GitHub issues for this exact setup.
- Forgetting to approve advertised routes. Running
--advertise-routeswithout also approving the route in the admin console leaves the subnet completely unreachable, and there is no error message on the CLI side to warn you. - Leaving the systemd unit disabled on Arch Linux. The tailnet connection works fine until the next reboot, then silently fails to reconnect because
tailscaled.servicewas never enabled. - Skipping the “known proxies” configuration behind a reverse proxy. Self-hosted apps like Jellyfin will log every request as coming from the proxy’s tailnet IP, breaking per-user rate limiting and audit trails.
- Using a reusable auth key for automated provisioning. A reusable key committed accidentally to a CI log or public repo can be used to enroll rogue devices until manually revoked.
- Forgetting
--exit-node-allow-lan-access. Without it, enabling an exit node also breaks access to local-only devices like smart TVs or network printers. - Writing an ACL rule with a HuJSON syntax error and saving it anyway. A malformed policy file can lock out every device on the tailnet simultaneously; always run it through the admin console’s built-in simulator first.
- Assuming MagicDNS resolves automatically without enabling it. It is off by default on new tailnets and has to be turned on explicitly in the DNS tab.
Troubleshooting Tailscale Connection Issues
| Symptom | Likely Cause | Fix |
|---|---|---|
| tailscale status shows “relay” instead of “direct” | NAT traversal failed, often due to symmetric NAT or a restrictive firewall | Traffic still works via DERP relay; check firewall UDP rules if lower latency is required |
| Subnet route advertised but unreachable from clients | Route not approved in admin console | Approve the route under the advertising device’s settings in Machines |
| Exit node shows in list but clients can’t select it | Exit node capability not approved by admin | Approve the exit node flag in the admin console before setting –exit-node on clients |
| tailscale ssh connection refused | SSH not enabled on target, or ACL denies it | Run sudo tailscale set –ssh on target and verify ACL allows the src group |
| Device drops off tailnet after reboot | tailscaled systemd unit not enabled | sudo systemctl enable –now tailscaled.service |
| MagicDNS names don’t resolve | MagicDNS disabled at the tailnet level | Enable MagicDNS in the admin console’s DNS tab |
| New device can’t join despite valid login | Device approval required setting is on and device is pending | Approve the pending device manually under Machines |
| ACL change locked everyone out | Syntax error or overly restrictive rule saved without testing | Roll back via the admin console’s policy file history, then re-test in the simulator |
| Auth key rejected on headless server | Key expired or was single-use and already consumed | Generate a fresh key from the Keys tab in the admin console |
| High latency between two nearby devices | Traffic routing through a distant DERP relay | Check NAT type; consider opening UDP 41641 outbound to enable direct connections |
What Tailscale Protects Against, and What It Does Not
It is worth being precise about the boundary of what this setup actually buys you, since overclaiming security tools is how teams end up with a false sense of coverage. Tailscale protects the transport layer: traffic between authorized devices is encrypted end-to-end via WireGuard, and a device that is not explicitly authorized cannot reach anything on the tailnet regardless of network position. That closes off a huge class of network-level attacks, including passive eavesdropping on shared Wi-Fi and the kind of flat-network lateral movement that made the 2020 SolarWinds-style incidents so damaging once an attacker got a single foothold.
What it does not do is replace endpoint security. A device that is authorized on the tailnet and also compromised by malware is still authorized; Tailscale enforces network-level access, not the integrity of the device itself. It also does not replace application-layer authentication. Putting a database behind an ACL rule that allows tag:platform-team to reach port 5432 is a meaningful improvement over exposing that port to the whole office network, but the database still needs its own credentials, and those credentials still need to be rotated and scoped independently. Treat a tailnet ACL as one layer in a defense-in-depth stack, sitting alongside endpoint detection, database-level auth, and standard patching hygiene, not as a replacement for any of them.
There is also a dependency worth naming honestly: Tailscale’s coordination server is a piece of infrastructure you do not control. Device-to-device traffic itself is encrypted end-to-end and does not pass through Tailscale’s servers except when falling back to a DERP relay, but the coordination plane that distributes keys and enforces the ACL policy is a third-party service. Teams with strict data-residency or air-gapped requirements sometimes run Headscale, an open-source, self-hosted reimplementation of the coordination server, specifically to remove that dependency, at the cost of losing Tailscale’s managed updates and official support.
Advanced Tips for Production Tailnets
Tag every non-personal device from the day it joins the tailnet, rather than relying on user identity alone. A server tagged tag:prod-api can have ACL rules written against the tag, which survives employee turnover; a rule written against a specific person’s account breaks the moment that person leaves.
Run more than one exit node if your team is geographically distributed, and let each region’s clients default to the nearest one rather than routing everyone through a single VM on the other side of the planet. Latency compounds fast when full-tunnel traffic takes a detour.
Pair Tailscale SSH’s session recording with a log shipper pointed at your existing SIEM. Tailscale itself does not replace centralized log retention, it generates the audit trail; someone still has to store and alert on it.
Review the ACL file in version control. Treat it like infrastructure code: pull requests, a diff before merge, and a rollback plan. The admin console’s UI editor is fine for quick changes, but a tailnet with more than a handful of tags and groups gets unreadable fast without a proper git history behind the policy file.
Finally, budget for periodic access reviews rather than treating the initial ACL setup as permanent. Quarterly is a reasonable cadence for most teams: pull the current tag assignments, cross-check them against who actually still needs that access, and prune anything left over from a project that wrapped up months ago. Stale ACL entries are the zero-trust equivalent of an old shared password nobody remembers changing, quietly widening the blast radius of any future compromise.
Complete Working Project: A Three-Node Zero-Trust Tailnet
Putting every step together, here is the full sequence for a realistic small deployment: a home server, a cloud VM acting as both subnet router and exit node, and a laptop.
# On the home server (Ubuntu 24.04)
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --advertise-tags=tag:home
sudo tailscale set --ssh
# On the cloud VM (Debian 12) - subnet router + exit node
curl -fsSL https://tailscale.com/install.sh | sh
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
sudo tailscale up \
--advertise-routes=192.168.1.0/24 \
--advertise-exit-node \
--advertise-tags=tag:cloud-router
# On the laptop (macOS)
brew install tailscale
sudo tailscale up --accept-routes
tailscale up --exit-node=100.64.33.4 --exit-node-allow-lan-access
# Verify from the laptop
tailscale status
tailscale ssh user@home-serverAfter running each command, log into the admin console once to approve the advertised route and the exit node flag on the cloud VM, and to write an ACL rule scoping which tags can reach tag:home over SSH. That single console visit is the zero-trust checkpoint that a flat, no-approval-needed mesh would skip entirely.
Frequently Asked Questions
Is Tailscale free for personal use?
Yes. As of September 2026 the free tier supports up to 6 users with unlimited devices per user, which covers most home labs and small teams without a subscription.
Does Tailscale replace WireGuard, or run on top of it?
Tailscale runs on top of WireGuard. It uses the WireGuard protocol for the actual encrypted tunnels, then adds identity-based authentication, NAT traversal, key distribution, and access control on top, none of which raw WireGuard provides out of the box.
Can I use Tailscale without opening any firewall ports?
Yes. If direct peer-to-peer connections fail due to NAT, Tailscale falls back to relaying traffic through its DERP servers, at some latency cost, without requiring any inbound port to be opened.
What is the difference between a subnet router and an exit node?
A subnet router exposes a specific local network range to tailnet clients. An exit node routes all of a client’s internet-bound traffic through another device, not just tailnet-destined traffic. A single device can do both at once.
Why do I need to approve routes in the admin console if I already advertised them from the CLI?
This two-step design prevents a single compromised or misconfigured device from silently exposing an entire subnet or becoming an exit node without an administrator’s explicit sign-off, which is a core part of the zero-trust model.
Does Tailscale SSH replace my existing SSH keys entirely?
It can, since access is authorized through the tailnet identity and ACL policy rather than a static key pair. Many teams run it alongside existing keys during a transition period rather than removing SSH key auth on day one.
Is Tailscale suitable for a business with compliance requirements?
Tailscale SSH supports session audit logging, and the tag-and-ACL model maps reasonably well onto least-privilege requirements common in SOC 2 and similar frameworks, though the logs still need to be shipped to and retained in your own SIEM or log store.
What happens if I lose a device that was on my tailnet?
Revoke it immediately from the admin console’s Machines tab. If key expiry is enabled (the default, 180 days), an unrevoked but abandoned device also loses access automatically once its key expires.
What is Tailscale Funnel and how is it different from an exit node?
Funnel exposes one specific local service on one device to the public internet over HTTPS. An exit node does the opposite: it routes an already-authenticated tailnet client’s outbound traffic through another device. Funnel is for letting outsiders in to a single service; exit nodes are for letting insiders’ traffic out through a chosen path.
Do I need a paid plan to use ACLs and tags?
No. Access control lists, tagging, subnet routers, and exit nodes are all available on the free tier. Paid tiers add SSO enforcement, audit logging, session recording, and SCIM provisioning, features that matter for larger or regulated teams rather than for a basic zero-trust setup.
Related Coverage
- How to Enable Fortnite 2FA: 12 Steps, Free Rewards [2026]
- How to Set Up OWASP ZAP: 12 Steps, 90 Min, $0 Cost [2026]
- How to Recover a Hacked Steam Account: 12 Steps [2026]
- How to Use Nmap for Network Scanning: 12 Steps [2026]
- Wallpaper Engine Malware Removal: 12 Steps, 2 CVEs [2026]
