Tailscale VPN Security Hardening and Best Practices

Introduction to Tailscale VPN Security

Tailscale is a zero-config Virtual Private Network (VPN) built on top of WireGuard. Instead of creating a traditional hub-and-spoke VPN tunnel where all traffic routes through a central gateway, Tailscale creates a peer-to-peer mesh network. Devices authenticate directly to each other, establishing encrypted tunnels only between the nodes that need to communicate.

Why does this matter for security? Traditional VPNs often grant broad network access once a user is connected, creating a massive lateral movement risk if a device is compromised. Tailscale shifts the security paradigm from perimeter-based to identity-based. Access is tied to user identity (via Single Sign-On) and specific device posture, meaning users only reach the exact services they are authorized to use. However, out of the box, Tailscale's default configuration is relatively permissive. Hardening your Tailscale network is essential to fully leverage its zero-trust capabilities.

Implementing Access Control Lists (ACLs)

The most critical step in securing a Tailscale network is configuring Access Control Lists (ACLs). By default, Tailscale allows all connected devices to communicate with each other. In a production environment, this violates the principle of least privilege. ACLs allow you to define exactly which users and devices can talk to which ports on which nodes.

Tailscale ACLs are written in JSON and managed via the Tailscale admin console or the Tailscale API. You should define groups, tag devices, and explicitly allow only necessary traffic.

Example: Restrictive ACL Configuration

Below is an example of a hardened ACL configuration. It defines a group for developers, assigns tags to servers, and restricts access so developers can only reach SSH (port 22) and HTTP/HTTPS on the web servers, and nothing else.

{
  "tagOwners": {
    "tag:web-server": ["group:devs"],
    "tag:db-server": ["group:devs"]
  },
  "groups": {
    "group:devs": ["developer@example.com"]
  },
  "acls": [
    {
      "action": "accept",
      "src": ["group:devs"],
      "dst": [
        "tag:web-server:22",
        "tag:web-server:80",
        "tag:web-server:443"
      ]
    },
    {
      "action": "accept",
      "src": ["tag:web-server"],
      "dst": ["tag:db-server:5432"]
    }
  ],
  "ssh": [
    {
      "action": "accept",
      "src": ["group:devs"],
      "dst": ["tag:web-server"],
      "users": ["root", "ubuntu"]
    }
  ]
}

In this configuration, developers cannot directly access the database server; only the web servers can communicate with the database over port 5432. This prevents lateral movement if a developer's machine is compromised.

Enforcing Device Posture and Authentication

Identity is only one half of the zero-trust equation; device health is the other. Tailscale provides several features to ensure that only secure, authenticated devices can join and remain on your network.

Key Expiry and Reauthentication

Tailscale uses cryptographic keys to authenticate devices. By default, these keys do not expire. You should enforce key expiry to ensure devices must periodically re-authenticate with your Identity Provider (IdP). This ensures that if a device is stolen or an employee leaves, their access is automatically revoked after a set period unless actively renewed.

You can set key expiry globally or per-device. To check the status of a device's keys via the Tailscale API, you can use the following curl command:

curl -s -H "Authorization: Bearer YOUR_TAILSCALE_API_KEY" \
  https://api.tailscale.com/api/v2/device/DEVICE_ID | jq '.keyExpiryDisabled, .authorized'

Device Posture Checks

Tailscale's device posture feature allows you to restrict access based on the state of the endpoint. You can require that connecting devices have specific operating systems, disk encryption enabled, or specific software running. If a device fails the posture check, it is denied access to restricted nodes even if the user's identity is valid.

Network and Routing Hardening

Tailscale can act as a subnet router to expose local network subnets to the tailnet, or as an exit node to route all internet traffic. While powerful, these features must be hardened to prevent unintended exposure.

Securing Subnet Routers and Exit Nodes

When configuring a subnet router, be as specific as possible with your CIDR blocks. Avoid advertising 0.0.0.0/0 unless you are intentionally setting up an exit node. Furthermore, use ACLs to restrict which users can access the advertised subnets.

If you are setting up an exit node on a Linux machine, you must enable IP forwarding. Here is the standard way to configure a Linux exit node securely:

# Enable IP forwarding temporarily
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward
echo 1 | sudo tee /proc/sys/net/ipv6/conf/all/forwarding

# 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

# Advertise the device as an exit node
sudo tailscale up --advertise-exit-node

Once advertised, the exit node must be approved in the Tailscale admin console. Ensure that only trusted administrators are allowed to use exit nodes, as all their internet traffic will appear to originate from the exit node's IP address.

Best Practices for Tailscale Administrators

To maintain a robust security posture, administrators should adopt the following ongoing practices:

Use SSO with MFA: Never use email-based authentication for your tailnet. Integrate Tailscale with an Identity Provider (like Okta, Azure AD, or Google Workspace) and enforce Multi-Factor Authentication (MFA) for all users.
Tag Your Devices: Do not rely on user ownership to define access rules for infrastructure. Use Tailscale tags (e.g., tag:prod, tag:staging) to decouple machine access from individual user identities.
Restrict MagicDNS: While MagicDNS makes it easy to resolve nodes by name, ensure your ACLs are strict. If MagicDNS is not required, consider disabling it to reduce the attack surface.
Audit Regularly: Use the Tailscale API to regularly pull network logs and audit which devices are connected, who authorized them, and what ACLs are in place. Remove stale devices immediately.
Enable Tailscale SSH Cautiously: Tailscale SSH allows passwordless, keyless SSH access based on tailnet identity. While it eliminates SSH key management, ensure your ACLs strictly define who can SSH into which tagged devices and as which user.

Conclusion

Tailscale provides a powerful foundation for a zero-trust network, but its security is only as strong as its configuration. By moving away from the default permissive settings and implementing strict Access Control Lists, enforcing device posture and key expiry, and carefully managing subnet routing and exit nodes, you can create a highly resilient network environment. Security is an ongoing process, and regularly auditing your Tailscale deployment against these best practices will ensure your infrastructure remains protected against evolving threats.