What exactly is Tailscale, and what advantages does it offer over traditional VPN connections?

Tailscale is a VPN service that connects devices to a private network known as a tailnet. Technically, it is based on WireGuard. The difference from a traditional corporate VPN lies in the topology: devices establish their encrypted tunnels directly with one another (mesh). There is no central VPN concentrator through which all traffic flows. Only management remains centralized: a coordination server distributes public keys, addresses, and access rules, but does not see the payload data itself.

To get started, all you need is an account with an identity provider (Microsoft, Google, GitHub, Apple, or an OIDC provider) and the client on each device. Firewall port forwarding is generally not necessary. This makes Tailscale popular both for home networks and for remote access to servers and customer systems.

How a traditional VPN works

A traditional remote-access VPN works according to the hub-and-spoke principle. At the edge of the corporate network is a VPN gateway (firewall or appliance) that is reachable from the internet. The client on the laptop establishes a tunnel to this gateway; common options are IPsec/IKEv2 (UDP 500 and 4500), SSL VPN variants over TCP 443, or OpenVPN. After signing in, the device receives an address from a pool and routes to the internal networks.

This model has proven itself over decades, but it comes with structural characteristics that create operational effort today:

• Publicly reachable gateway: The VPN concentrator must be reachable from the internet, making it a preferred target for attacks. Vulnerabilities in VPN appliances have repeatedly been actively exploited in recent years; in January 2024, the U.S. agency CISA even ordered affected Ivanti gateways to be disconnected from the network through Emergency Directive 24-01.
• Single point of failure and bottleneck: All traffic passes through the gateway. If it fails or bandwidth is exhausted, all users are affected at once.
• Detours (hairpinning): If two employees working from home access the same cloud server, traffic first goes to the data center and then back out again.
• Coarse access rights: Once the connection is established, the device often has access to an entire network segment. Fine-grained rules per user and service are possible, but are rarely maintained consistently.
• Site-to-site effort: Every additional site needs its own tunnel with coordinated parameters (Phase 1/Phase 2 proposals, pre-shared keys or certificates, static public IP addresses).

How Tailscale is structured

Tailscale separates the control plane from the data plane. The control plane is the coordination server, which Tailscale operates as a cloud service. The data plane consists of the WireGuard tunnels between devices.

A device’s private key never leaves the device. The coordination server knows only the public keys and therefore cannot decrypt traffic. Each device receives a static address from the 100.64.0.0/10 range (the address space for carrier-grade NAT), as well as an IPv6 address from fd7a:115c:a1e0::/48. With MagicDNS, devices are also reachable by name, for example nas or nas.tailnet-name.ts.net.

NAT traversal: why no port forwarding is needed

Most devices are behind a NAT router or firewall and cannot be reached directly from outside. Tailscale solves this using NAT traversal: both sides determine their public address and assigned port through STUN, exchange this information through the coordination server, and simultaneously send UDP packets to each other. The outbound packets open a state entry on both firewalls, through which the other side’s packets can subsequently enter (UDP hole punching).

If this fails, for example with restrictive firewalls that block outbound UDP or with certain forms of carrier-grade NAT, traffic is routed through a DERP relay via HTTPS. It remains end-to-end encrypted with WireGuard there as well; the relay sees only encrypted packets. The trade-off is higher latency and lower throughput. Peer relays reduce this disadvantage by having an internal device with good connectivity handle forwarding.

The advantages over a traditional VPN

Smaller attack surface

Because clients establish their connections outbound, no device needs an open internet port. A server intended to be reachable only through the tailnet can bind its services exclusively to the Tailscale interface. It is then invisible to internet port scanners. With around 4,000 lines of kernel code, WireGuard itself is considerably smaller than typical IPsec or SSL VPN implementations and uses a fixed set of modern primitives (Curve25519, ChaCha20-Poly1305, BLAKE2s). There is no negotiation of cipher suites, which regularly leads to misconfigurations with IPsec.

Identity instead of network address

Every device in the tailnet is associated with a user or a tag. Sign-in takes place through the identity provider you already use; MFA and Conditional Access from Microsoft Entra ID therefore also apply to network access. New devices can join the tailnet only after successfully signing in with the identity provider, and every device key expires after 180 days by default. If an employee leaves the company, you disable the account in the identity provider; with SCIM provisioning (from the Standard plan onward), the user is automatically disabled in the tailnet and their devices lose access.

Access rules based on the principle of least privilege

By default, every device in a new tailnet can reach every other device. For production use, define access rights in a centralized policy file (HuJSON). The following example allows the administrators group SSH and HTTPS access to all servers tagged tag:server, while all other users are allowed HTTPS access only to the intranet server:

{
  "groups": {
    "group:admins": ["admin@example.com"]
  },
  "tagOwners": {
    "tag:server": ["group:admins"]
  },
  "grants": [
    {
      "src": ["group:admins"],
      "dst": ["tag:server"],
      "ip":  ["tcp:22", "tcp:443"]
    },
    {
      "src": ["autogroup:member"],
      "dst": ["intranet"],
      "ip":  ["tcp:443"]
    }
  ],
  "hosts": {
    "intranet": "100.101.102.103"
  }
}

Each client enforces the rules locally. A packet not allowed by the policy is discarded by the destination device. The coordination server only distributes the policy.

Direct connections instead of detours

Because tunnels exist directly between devices, traffic takes the shortest route. Two devices in the same office communicate locally, while a laptop working from home reaches a cloud server directly. This reduces latency and relieves the main site’s internet connection.

Connecting existing networks

Not every device can run a Tailscale client, such as printers, older NAS systems, or industrial controllers. In these cases, a subnet router takes on the role of a gateway: a Linux server in the target network advertises the local subnet in the tailnet, and authorized devices can reach it through that server.

curl -fsSL https://tailscale.com/install.sh | sh
echo 'net.ipv4.ip_forward = 1' | \
  sudo tee /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale up \
  --advertise-routes=192.168.10.0/24 \
  --advertise-tags=tag:server

The advertised route must then be approved in the admin console unless automatic approval (autoApprovers) is configured in the policy. Similarly, a device can be operated as an exit node with --advertise-exit-node. Clients that select this exit node then route all their internet traffic through it, corresponding to the full-tunnel mode of a traditional VPN.

Less operational overhead

The coordination server manages key rotation, address assignment, DNS, and routing. A new site needs a subnet router with internet access, but no static public IP address and no coordination of IPsec parameters with the other side. For remote server access, Tailscale SSH (sign-in using tailnet identity without distributed SSH keys) and tailscale serve (sharing a local web service within the tailnet) are also available.

Limitations and dependencies

Tailscale replaces the traditional VPN gateway, but shifts part of the responsibility to an external service. You should review these points before deployment.

For companies in Switzerland, the revised Federal Act on Data Protection (revFADP) applies. Because the vendor processes users’ personal data (accounts, devices, connection metadata), list Tailscale in your record of processing activities if your company is required to maintain one (from 250 employees onward or for high-risk processing). Review the vendor’s Data Processing Addendum and the legal basis for disclosure abroad under Art. 16 revFADP, such as certification under the Swiss-U.S. Data Privacy Framework or standard contractual clauses. If processing data by the vendor is excluded, Headscale remains available as a self-operated control plane.

EU note: For branches in the EU, the GDPR and its rules on transfers to third countries apply (Art. 44 et seq. GDPR). The assessment is substantively similar; the EU-U.S. Data Privacy Framework is the relevant framework there.

Costs

The Personal plan is free and includes up to six users, unlimited user devices, and 50 tagged devices (as of October 2026). For business use, the Standard plan costs USD 8 and Premium costs USD 18 per user per month. Premium adds Network Flow Logs, log streaming, and advanced options for Tailscale SSH, among other features. Enterprise is offered individually.

Who Tailscale is suitable for

Tailscale is especially suitable when users and resources are distributed: remote work, cloud servers with multiple vendors, small branch locations without a static IP address, or remote maintenance at customer sites. For small and medium-sized businesses, it can completely replace a VPN gateway. In larger environments, it often runs alongside the existing VPN, for example for administrative access to servers, where its fine-grained access rules provide the greatest benefit.

It is less suitable if requirements mandate a fully self-operated infrastructure and Headscale does not cover the required functionality, or if all internet traffic must be filtered centrally. In this case, a Secure Web Gateway remains necessary to complement Tailscale.

For testing, simply install the client on two devices and sign in with the same account. You can then use tailscale status to see all devices in the tailnet and tailscale ping <gerät> to check whether a direct connection or a relay is being used.