Tailscale: The Zero-Trust Network That Changed How I Manage Infrastructure

Introduction: Rethinking Network Access

For years, managing remote access to my infrastructure followed the same tired pattern: OpenVPN configurations that broke after updates, port forwarding that exposed services to the internet, or restrictive firewalls that made simple SSH access feel like navigating a maze.

I currently still use a VPN that I manage and run via the old methodology, peer management, server etc but as a form of redundancy Tailscale is, for me, the gold standard.

What started as a curiosity became indispensable within weeks. Today, Tailscale forms the backbone of how I access every system I manage—from Windows servers to Linux VPS instances, from home lab machines to cloud infrastructure scattered across providers.

This isn’t hyperbole. Tailscale has fundamentally changed how I think about network security, remote access, and infrastructure management. And I’m far from alone: as of 2025, Tailscale powers networks for over 2 million users and thousands of enterprises, from startups to Fortune 500 companies. All the while they have a great youtube channel https://www.youtube.com/@Tailscale and remain accessible for end user providing first rate end-user support and do seem to be doing things very differently.

This guide aims to be definitive. Not just “what is Tailscale,” but:

• How it actually works under the hood (WireGuard, DERP, coordination servers)
• Exhaustive use cases (you’ll discover applications you never considered)
• Practical implementation (step-by-step Windows and Linux setup)
• Real-world configurations (SSH hardening, SMB tunneling)
• Company deep-dive (history, team, business model, funding)
• Critical analysis (strengths, limitations, the centralization concern)

By the end, you’ll understand not just what Tailscale does, but why it represents a paradigm shift in how we approach network connectivity in an increasingly distributed world.

Why This Matters Now

The traditional perimeter is dead. Employees work from home, services run in multiple clouds, infrastructure spans continents, and the “castle-and-moat” security model collapsed under the weight of modern reality.

Yet most networking tools were designed for that old world:

• VPNs that require complex server infrastructure
• Port forwarding that punches holes in firewalls
• Jump boxes that add latency and failure points
• SSH key management across dozens of systems
• Firewall rules that become unmaintainable

Tailscale solves this with radical simplicity: Install an app. Authenticate. Your devices are now securely connected. No servers to maintain. No ports to forward. No complex routing tables.

But simple doesn’t mean simplistic. Underneath is sophisticated technology—WireGuard encryption, NAT traversal, zero-trust authentication, mesh networking—deployed so elegantly that it “just works.”

Let’s explore how.

Part 1: Understanding Tailscale - Technology Deep Dive

What Tailscale Is (and Isn’t)

Tailscale is:

• A mesh VPN (every device connects directly to every other device)
• Zero-trust by default (authentication required, nothing trusted by IP alone)
• Based on WireGuard (modern, fast, cryptographically sound protocol)
• A coordination service (handles authentication, key exchange, NAT traversal)
• Cross-platform (Windows, Linux, macOS, iOS, Android, BSD)

Tailscale is not:

• A traditional VPN service (no centralized VPN server)
• Anonymous browsing tool (not designed to hide your identity)
• Replacement for all firewalls (complements existing security)
• Free from all cloud dependencies (uses Tailscale coordination servers)

The Key Insight: Traditional VPNs route all traffic through central servers. Tailscale creates direct, encrypted connections between devices (peer-to-peer) while using cloud coordination only for initial setup and NAT traversal.

The WireGuard Foundation

To understand Tailscale, you must understand WireGuard.

What Is WireGuard?

WireGuard is a modern VPN protocol created by Jason A. Donenfeld, first released in 2016 and merged into the Linux kernel in 2020. It represents a complete rethinking of VPN technology.

Traditional VPN Protocols (OpenVPN, IPsec):

• Hundreds of thousands of lines of code
• Complex configuration (cryptographic options, cipher suites)
• Multiple encryption paths and legacy support
• Difficult to audit, prone to vulnerabilities

WireGuard:

• Under 4,000 lines of code
• Single, opinionated cryptographic suite
• Designed for auditability and correctness
• Dramatically faster than alternatives

Technical Specifications:

Cryptography:

• Encryption: ChaCha20 with Poly1305 authentication
• Key exchange: Curve25519
• Hashing: BLAKE2s
• All modern, well-vetted algorithms

Performance:

• 1.5-3x faster than OpenVPN on typical hardware
• Minimal CPU overhead (great for embedded devices)
• Maintains performance even with packet loss
• Low latency (crucial for SSH, remote desktop)

Design Philosophy:

• “Cryptokey routing” - Public keys serve as identity
• Silent by default (doesn’t respond to unauthenticated traffic)
• Roaming support (handles IP address changes seamlessly)
• Minimal attack surface

Why This Matters for Tailscale: Tailscale builds on WireGuard’s rock-solid foundation, handling the complex parts (key distribution, authentication, NAT traversal) while preserving WireGuard’s performance and security benefits.

Tailscale’s Architecture: How It Actually Works

The Three-Layer System

Layer 1: The Tailscale Application (Client) Runs on each device. Responsibilities:

• Establishes WireGuard tunnels to other devices
• Manages local firewall rules
• Handles DNS configuration
• Monitors connection health
• Facilitates NAT traversal

Layer 2: The Coordination Server (Control Plane) Runs in Tailscale’s cloud (or self-hosted with Headscale). Responsibilities:

• User authentication (SSO, OAuth, etc.)
• Device authorization and access control
• Distributes public keys to devices
• Coordinates initial connection setup
• Provides DERP relay information
• Does NOT see or route your traffic

Layer 3: DERP Relay Servers (Fallback Path) Distributed globally. Responsibilities:

• Relay encrypted traffic when direct connection impossible
• Only used when NAT traversal fails
• Cannot decrypt traffic (end-to-end encrypted)
• Automatically selected based on latency

Connection Establishment: Step-by-Step

When you add a new device to your Tailscale network:

Step 1: Authentication (30 seconds)

User → Tailscale App → Coordination Server
↓
Authentication via SSO (Google, Microsoft, GitHub, etc.)
↓
Device registered, assigned 100.x.y.z IP address
↓
Access controls evaluated (ACLs determine what device can reach)

Step 2: Key Exchange (5 seconds)

Device A generates WireGuard key pair
↓
Public key sent to Coordination Server
↓
Coordination Server distributes public keys to authorized devices
↓
All devices now have each other's public keys

Step 3: NAT Traversal (10-30 seconds)

Device A wants to connect to Device B
↓
Both devices exchange their:
  - Public IP addresses
  - Available ports
  - NAT type information
↓
Tailscale attempts direct connection methods:
  1. Direct connection (both devices publicly accessible)
  2. Hole-punching (works in ~75% of NAT scenarios)
  3. DERP relay (fallback if direct connection fails)

Step 4: Encrypted Tunnel Established

WireGuard tunnel established using exchanged keys
↓
All traffic encrypted end-to-end
↓
Coordination Server no longer involved in data path
↓
Traffic flows directly between devices (or via DERP if necessary)

The Beautiful Part: This entire process is automatic. From the user’s perspective: “I installed an app and now I can SSH to my servers.” The complexity is completely abstracted.

The DERP System: Encrypted Relay Network

DERP (Designated Encrypted Relay for Packets) deserves special attention because it’s often misunderstood.

What DERP Is:

• A fallback relay system for when direct connections fail
• Approximately 75-80% of connections are direct; 20-25% use DERP
• Used temporarily until NAT traversal succeeds
• Encrypted end-to-end (DERP servers cannot read your data)

When DERP Is Used:

• Symmetric NAT on both sides (hole-punching impossible)
• Restrictive corporate firewalls blocking UDP
• Mobile devices switching networks frequently
• Initial connection while hole-punching is attempted

Why DERP Is Brilliant: Traditional VPNs fail when direct connections are impossible. Tailscale gracefully falls back to relay while continuously attempting to establish direct connections. Users never notice.

Global DERP Infrastructure: Tailscale operates DERP servers in major cities worldwide:

• North America: New York, San Francisco, Chicago, Dallas, Toronto
• Europe: London, Frankfurt, Paris, Warsaw
• Asia: Tokyo, Singapore, Sydney, Bangalore
• South America: São Paulo

Your client automatically selects the lowest-latency DERP server. Most connections upgrade to direct after DERP facilitates initial handshake.

Zero-Trust Security Model

Traditional VPN Model (Implicit Trust):

You're on the VPN → You can access everything on the network

Tailscale Zero-Trust Model:

You're authenticated → Device is authorized → ACLs determine access

Key Differences:

1. No Implicit Trust by Network Location

• Being on the Tailscale network doesn’t grant access
• Every connection requires authorization
• Access control is per-device, per-user, per-service

2. Identity-Based Access Control

# Example Tailscale ACL
{
  "acls": [
    {
      "action": "accept",
      "src": ["group:engineers"],
      "dst": ["tag:production-servers:22"]
    }
  ]
}

Engineers can SSH to production servers. Nothing else is permitted.

3. Device Authorization

• Every device must be explicitly approved
• Device keys can be revoked instantly
• Per-device authentication requirements
• Optional re-authentication intervals

4. Minimal Attack Surface

• No listening ports on public internet (unless specifically configured)
• WireGuard is “silent” to unauthenticated probes
• Cannot be port-scanned or discovered
• Reduces attack surface to zero for most services

Network Topology: Mesh vs. Hub-and-Spoke

Traditional VPN (Hub-and-Spoke):

        [VPN Server]
           /   \
          /     \
    [Client A] [Client B]

All traffic flows through central server.

Tailscale (Full Mesh):

    [Device A] ←→ [Device B]
         ↑            ↑
         |            |
         ↓            ↓
    [Device C] ←→ [Device D]

Every device can connect directly to every other device.

Advantages of Mesh:

• Lower Latency: Direct connections eliminate middleman
• Higher Throughput: No server bottleneck
• Better Reliability: Single device failure doesn’t affect others
• Reduced Costs: No bandwidth costs for central server
• Privacy: Traffic never touches Tailscale’s servers (except DERP fallback)

When Hub-and-Spoke Makes Sense: Tailscale supports “subnet routers” and “exit nodes” for cases where hub-and-spoke is needed:

• Accessing entire subnets (e.g., 192.168.1.0/24)
• Using device as VPN gateway for internet traffic
• Connecting legacy systems that can’t run Tailscale

IP Addressing and DNS

Tailscale IP Addresses (100.x.y.z):

• Uses CGNAT space (100.64.0.0/10) - RFC 6598
• Stable across network changes
• Assigned per-device, persists forever
• Example: 100.101.102.103

Tailscale DNS (MagicDNS): Every device gets a hostname:

device-name.tail<xxx>.ts.net

Example:

# Instead of remembering 100.101.102.103
ssh andrew@orion-server.tail9ab42c.ts.net

# Or with custom domain (Tailscale DNS feature)
ssh andrew@orion.ajolnet.com

Split DNS: Tailscale can resolve both:

• Tailscale network names (devices on your network)
• Public DNS names (regular internet)

DNS Search Domains: Configure search domains so:

ssh orion    # Automatically resolves to orion.tail<xxx>.ts.net

Part 2: Use Cases - The Power of Tailscale

This section explores the breadth of what Tailscale enables. Some use cases are obvious; others may surprise you.

1. SSH Access: The Foundation

The Traditional Problem:

• Port 22 exposed to internet → Constant brute force attacks
• Jump boxes → Added latency and management overhead
• VPN servers → Infrastructure to maintain, single point of failure
• Changing IPs → SSH configs constantly outdated

The Tailscale Solution:

# On server (after Tailscale install)
# SSH listens only on Tailscale interface
sudo systemctl start tailscaled
tailscale up

# Configure SSH to listen only on Tailscale IP
# /etc/ssh/sshd_config
ListenAddress 100.x.y.z

# From anywhere in the world
ssh andrew@server-name.tail<xxx>.ts.net

What This Achieves:

• ✓ No exposed ports on public internet
• ✓ No brute force attacks (service isn’t discoverable)
• ✓ No VPN server to maintain
• ✓ No port forwarding configuration
• ✓ Works from anywhere (mobile, client networks, hotels)
• ✓ Automatic failover if server IP changes
• ✓ Built-in access logging via Tailscale

My Personal Setup: I manage 8 VPS instances across 3 providers (OVH, Hetzner, AWS) plus home lab infrastructure. Before Tailscale:

• Had to remember different IPs/ports
• Maintained SSH config file with 20+ entries
• Exposed SSH ports (even with fail2ban, constant attacks)
• Worried about SSH key distribution

After Tailscale:

• ssh orion connects to home server
• ssh vps-blog connects to blog server
• ssh cloud-01 connects to AWS instance
• All via direct, encrypted WireGuard tunnels
• Zero exposed ports
• Zero management overhead

Advanced: SSH Certificate Authority Tailscale can act as SSH CA:

# Enable SSH on Tailscale network
tailscale configure ssh

# Now any authorized user can SSH without key exchange
ssh user@any-tailscale-device

Tailscale handles key distribution automatically. This is transformative for teams.

2. SMB/CIFS File Sharing: Secure Anywhere Access

The Traditional Problem:

• SMB exposed to internet → Major security risk
• VPN required for remote access → Complex setup
• Cloud storage → Monthly costs, privacy concerns, slow
• Port forwarding → Exposes file server to attacks

The Tailscale Solution:

# Windows Server with shared folders
# After Tailscale installed, shares accessible via:
\\100.x.y.z\ShareName
\\server-name.tail<xxx>.ts.net\ShareName

# Linux Samba server
# Mount from Windows via Tailscale IP
# Or from Linux:
sudo mount -t cifs //100.x.y.z/share /mnt/share

What This Achieves:

• ✓ File server never exposed to internet
• ✓ Access from anywhere (work, home, mobile)
• ✓ Full LAN speed on local network
• ✓ WireGuard encryption over internet
• ✓ No cloud storage costs
• ✓ Complete data ownership

Real-World Example: I run a Windows Server 2022 file server at home with:

• Family photos (500GB)
• Document archives
• Media library
• Backup storage

With Tailscale:

• Access from laptop when traveling
• Family members connect from their homes
• Automated backups from VPS to home server
• Never exposed SMB ports (notorious for ransomware)
• Zero monthly cloud storage costs

Performance Note: SMB over Tailscale performs remarkably well:

• Local network: Full gigabit (no Tailscale overhead)
• Remote (direct connection): Limited by internet speeds, ~5-10ms added latency
• Remote (DERP relay): ~50-100ms added latency, still very usable

3. Remote Desktop: RDP, VNC, GUI Access

Use Case: Access Windows Remote Desktop or Linux GUI sessions securely.

Traditional Approach:

• RDP exposed to internet → Constant attack target
• VPN required → Complex configuration
• Jump boxes → Added latency
• Or: Use third-party tools (TeamViewer, AnyDesk) → Privacy concerns, costs

Tailscale Approach:

# Windows RDP
mstsc /v:100.x.y.z
# Or
mstsc /v:windows-server.tail<xxx>.ts.net

# Linux VNC/RDP (xrdp)
rdesktop 100.x.y.z

Advantages:

• ✓ No exposed RDP port (eliminates 99% of attacks)
• ✓ Native RDP performance (no third-party overhead)
• ✓ Works from any network
• ✓ Encrypted via WireGuard
• ✓ Free (no per-user licensing like TeamViewer)

My Usage: I manage Windows Server infrastructure remotely. Before Tailscale, I ran RDP on non-standard ports and used VPNs. Attack logs showed thousands of brute-force attempts daily.

After Tailscale: Zero attacks (service isn’t discoverable). RDP on standard port 3389 listening only on Tailscale interface.

4. Subnet Routers: Accessing Entire Networks

Use Case: You have a network (home, office, datacenter) with devices that can’t run Tailscale. Access them via a Tailscale-enabled gateway.

Setup:

# On a device within the target network (e.g., Raspberry Pi)
sudo tailscale up --advertise-routes=192.168.1.0/24

# On Tailscale admin console, approve the routes

# Now from any Tailscale device
ssh user@192.168.1.50    # Direct access to non-Tailscale device
http://192.168.1.1       # Access router web interface

What This Enables:

• Legacy devices without Tailscale support
• IoT devices (cameras, smart home, NAS)
• Entire office networks
• Datacenter equipment
• Lab networks

Real-World Application: My home network has:

• Synology NAS (doesn’t run Tailscale natively)
• Security cameras
• Smart home hub
• Router admin interface

I configured a Raspberry Pi 4 as Tailscale subnet router. Now:

• Access NAS web interface from anywhere
• View security cameras remotely
• Manage smart home when traveling
• Configure router while away

All without port forwarding or exposing devices to internet.

5. Exit Nodes: Using Tailscale as Traditional VPN

Use Case: Route your internet traffic through another device on your Tailscale network.

Setup:

# On device you want to use as exit node (e.g., home server)
sudo tailscale up --advertise-exit-node

# On client device
tailscale up --exit-node=100.x.y.z

# Or select in GUI/mobile app

Why You’d Want This:

• Bypass geo-restrictions: Use home connection while traveling
• Secure public WiFi: Route through trusted device instead of untrusted network
• Access regional content: Use device in another country
• Consistent IP: Appear from home IP regardless of actual location

My Usage: When traveling, I use my home server as exit node to:

• Access UK streaming services
• Maintain consistent IP for services that flag VPNs
• Secure coffee shop WiFi connections
• Access home network resources and internet simultaneously

Performance: Excellent on direct connections, usable on DERP. Home server upload speed becomes bottleneck (my 50 Mbps upload limits remote speeds).

6. Multi-Cloud and Hybrid Infrastructure

Use Case: Connect resources across AWS, Azure, GCP, on-premise, and edge.

Example Architecture:

[AWS EC2 Instance] ←→ [Azure VM]
         ↑                 ↑
         |                 |
         ↓                 ↓
[On-Prem Server] ←→ [GCP Compute]

What This Enables:

• Cross-cloud private networking (no cloud VPN costs)
• Hybrid cloud (on-prem talking to cloud)
• Multi-region deployments
• Development/staging/production isolation
• Disaster recovery across providers

Real-World Example: I host services across:

• OVH (primary blog and services)
• Hetzner (backup and databases)
• Home server (testing and development)

With Tailscale:

• Databases communicate privately cross-provider
• Backup jobs run over Tailscale (encrypted, no VPN gateway)
• Development environment on home server talks to staging on Hetzner
• Zero VPN gateway costs
• No complex routing configurations

7. Container and Kubernetes Networking

Use Case: Connect containerized applications securely across environments.

Docker Integration:

# Run container with Tailscale sidecar
docker run -d \
  --name my-app \
  --network tailscale0 \
  my-app-image

Kubernetes:

• Tailscale operator for Kubernetes
• Each pod gets Tailscale IP
• Secure pod-to-pod communication across clusters

Why This Matters:

• Multi-cluster Kubernetes (production in cloud, dev local)
• Secure service mesh without additional tools
• Access k8s services from anywhere
• GitOps workflows with remote clusters

8. Development and Testing

Use Cases:

A) Local Development, Remote Testing:

Developer laptop (100.1.1.1) ←→ Test server (100.2.2.2)

Run service locally, test from remote device. Webhook callbacks work seamlessly.

B) Share Local Dev Environment: Your colleague can access your localhost via Tailscale:

# Your laptop runs dev server on :3000
# Colleague accesses: http://100.1.1.1:3000

C) Secure Staging Environments: Staging server on Tailscale, never exposed to internet. Only authenticated developers can access.

My Usage: When developing blog features:

• Run Hugo server locally
• Test from mobile via Tailscale
• Preview on tablet
• Show client work-in-progress via Tailscale link
• Never expose development server to internet

9. Database Access and Management

Use Case: Securely access databases without exposing ports.

Traditional Approach:

• SSH tunneling: ssh -L 5432:localhost:5432 server
• Expose database port: Security nightmare
• Bastion hosts: Additional infrastructure

Tailscale Approach:

# PostgreSQL server listens on Tailscale IP
listen_addresses = '100.x.y.z'

# Connect directly from database client
psql -h 100.x.y.z -U user dbname

# Or MySQL
mysql -h mysql-server.tail<xxx>.ts.net -u user -p

Advantages:

• ✓ No SSH tunnel maintenance
• ✓ No exposed database ports
• ✓ Database management tools work natively
• ✓ Multiple team members can connect
• ✓ Audit logging via Tailscale

My Setup:

• PostgreSQL on VPS (blog database)
• MySQL on home server (testing)
• Both accessible only via Tailscale
• Use pgAdmin/MySQL Workbench directly
• No SSH tunnels, no port forwarding

10. IoT and Edge Computing

Use Cases:

A) Raspberry Pi Remote Management:

# Pi running Tailscale
# SSH access from anywhere
ssh pi@rpi-sensor.tail<xxx>.ts.net

B) Edge Device Monitoring:

• Industrial sensors reporting to cloud
• Retail point-of-sale securely connected
• Digital signage management

C) Home Automation:

• Home Assistant behind Tailscale
• Security system accessible remotely
• Camera feeds without cloud services

11. Site-to-Site Networking

Use Case: Connect entire networks (office to office, office to home).

Setup:

# Office router (running Tailscale)
tailscale up --advertise-routes=192.168.10.0/24

# Home router (running Tailscale)
tailscale up --advertise-routes=192.168.1.0/24

# Now devices on both networks can communicate
Office computer (192.168.10.50) → Home NAS (192.168.1.100)

Traditional Alternative: Site-to-site VPN (complex configuration, dedicated hardware, expensive).

Tailscale Advantage: Software-defined, takes 5 minutes to configure, works with commodity hardware.

12. Collaborative Work Environments

Use Cases:

A) Freelancer/Contractor Access: Give contractor temporary access to specific servers:

{
  "acls": [
    {
      "action": "accept",
      "src": ["contractor@example.com"],
      "dst": ["tag:development:*"]
    }
  ]
}

Revoke access instantly when project ends.

B) Pair Programming: Share development environment without screen sharing:

# Junior developer accesses senior's machine for debugging
ssh senior@100.x.y.z
# Or mount remote filesystem
sshfs senior@100.x.y.z:/project ~/remote-project

C) Support Access: IT support can access end-user machines for troubleshooting:

# User installs Tailscale temporarily
# Support connects and assists
# User removes when done

13. Backup and Disaster Recovery

Use Cases:

A) Offsite Backups:

# Home server backs up to remote VPS via Tailscale
rsync -avz --delete /data/ backup@100.x.y.z:/backups/

B) Cross-Region Replication: Database replication over Tailscale (encrypted, direct connection).

C) Disaster Recovery Testing: Test DR procedures using Tailscale network without affecting production.

My Backup Strategy:

Home Server → (Tailscale) → VPS (France)
     ↓
Local NAS

Three-tier backup:

1. Local (fast recovery)
2. NAS (hardware failure protection)
3. Remote VPS (disaster recovery)

All via Tailscale. Secure, encrypted, no cloud backup costs.

14. Personal Use Cases

A) Family Tech Support:

• Parents’ computer has Tailscale
• I can connect to troubleshoot
• No fumbling with TeamViewer codes

B) Media Server Access:

• Plex/Jellyfin behind Tailscale
• Stream media anywhere
• No Plex subscription for remote access

C) Photo/Document Sync:

• Personal file server
• Access documents from any device
• No Google Drive/Dropbox costs

D) Password Manager:

• Self-hosted Vaultwarden on Tailscale
• Family access from anywhere
• Complete data ownership

15. Enterprise and Team Use Cases

A) Zero-Trust Corporate Network:

• Eliminate traditional VPN
• Every employee on Tailscale
• Access control via ACLs
• MFA enforcement
• Device posture checks

B) Contractor/Vendor Access:

• Time-limited access grants
• Specific resource permissions
• Instant revocation
• Full audit trail

C) Compliance and Audit:

• Complete connection logs
• User attribution
• Access control documentation
• Network segmentation

D) Multi-Region Operations:

• Offices worldwide on Tailscale mesh
• Direct inter-office communication
• Cloud resources integrated
• No expensive MPLS circuits

Part 3: Practical Implementation

Windows Installation and Configuration

Basic Installation

Step 1: Download and Install

1. Visit: https://tailscale.com/download/windows
2. Download Tailscale installer (MSI)
3. Run installer (requires admin rights)
4. Installation takes 30 seconds

Step 2: Initial Setup

1. Tailscale icon appears in system tray
2. Click icon → "Log in"
3. Browser opens for authentication
   - Choose: Google, Microsoft, GitHub, etc.
4. Authorize access
5. Device registered, assigned 100.x.y.z IP

Step 3: Verify Installation

# Open PowerShell
tailscale status
# Shows connected devices

tailscale ip -4
# Shows your Tailscale IP: 100.x.y.z

Your Windows machine is now on Tailscale network.

Configuring SSH Server on Windows (Via Tailscale)

Windows 10/11 and Server editions include OpenSSH server:

Step 1: Install OpenSSH Server

# PowerShell as Administrator
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

# Start SSH service
Start-Service sshd

# Set to start automatically
Set-Service -Name sshd -StartupType 'Automatic'

Step 2: Configure SSH to Listen on Tailscale Interface

# Get your Tailscale IP
tailscale ip -4
# Example: 100.101.102.103

# Edit SSH config
notepad C:\ProgramData\ssh\sshd_config

Add this line:

ListenAddress 100.101.102.103

Step 3: Configure Firewall

# Remove default SSH rule (allows all interfaces)
Remove-NetFirewallRule -Name "OpenSSH-Server-In-TCP"

# Create rule only for Tailscale interface
New-NetFirewallRule -Name 'OpenSSH-Server-Tailscale' `
  -DisplayName 'OpenSSH Server (Tailscale)' `
  -Enabled True `
  -Direction Inbound `
  -Protocol TCP `
  -Action Allow `
  -LocalPort 22 `
  -RemoteAddress 100.64.0.0/10

Step 4: Restart SSH Service

Restart-Service sshd

Step 5: Test Connection From another Tailscale device:

ssh andrew@100.101.102.103
# Or
ssh andrew@windows-server.tail<xxx>.ts.net

Result: SSH accessible only via Tailscale. Not exposed to public internet.

Configuring SMB File Shares via Tailscale

Step 1: Create Share (Normal Process)

1. Right-click folder → Properties → Sharing
2. Click "Share"
3. Add users and permissions
4. Click "Share"

Step 2: Configure Firewall for Tailscale Only

# Disable default SMB rules (too permissive)
Disable-NetFirewallRule -DisplayGroup "File and Printer Sharing"

# Create Tailscale-only SMB rules
New-NetFirewallRule -DisplayName "SMB-In (Tailscale)" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 445 `
  -RemoteAddress 100.64.0.0/10 `
  -Action Allow

New-NetFirewallRule -DisplayName "SMB-NB-In (Tailscale)" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 139 `
  -RemoteAddress 100.64.0.0/10 `
  -Action Allow

Step 3: Access Share from Other Devices

# Windows Explorer
\\100.101.102.103\ShareName
\\windows-server.tail<xxx>.ts.net\ShareName

# Map network drive
net use Z: \\100.101.102.103\ShareName

Result: File shares accessible only via Tailscale network.

Advanced: RDP via Tailscale

Step 1: Enable Remote Desktop

1. Settings → System → Remote Desktop
2. Toggle "Enable Remote Desktop" ON

Step 2: Configure Firewall

# Remove default RDP rule
Disable-NetFirewallRule -DisplayGroup "Remote Desktop"

# Create Tailscale-only rule
New-NetFirewallRule -DisplayName "RDP (Tailscale)" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 3389 `
  -RemoteAddress 100.64.0.0/10 `
  -Action Allow

Step 3: Connect

mstsc /v:100.101.102.103

Or Remote Desktop app with Tailscale hostname.

Linux Installation and Configuration

Installation (Debian/Ubuntu)

Step 1: Add Tailscale Repository

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/jammy.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list

Step 2: Install

sudo apt update
sudo apt install tailscale

Step 3: Start Tailscale

sudo tailscale up

Browser window opens for authentication. After authenticating, you’re connected.

Step 4: Verify

tailscale status
tailscale ip -4

SSH Configuration (Linux Server)

Goal: SSH accessible only via Tailscale, not public internet.

Step 1: Get Tailscale IP

tailscale ip -4
# Example output: 100.101.102.104

Step 2: Configure SSH to Listen on Tailscale IP

sudo nano /etc/ssh/sshd_config

Find and modify:

# Comment out or remove default
#Port 22
#ListenAddress 0.0.0.0

# Add Tailscale-specific listener
ListenAddress 100.101.102.104:22

Optional but Recommended:

# Additional hardening
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes

Step 3: Restart SSH

sudo systemctl restart sshd

Step 4: Configure Firewall (UFW)

# Deny SSH from public interfaces
sudo ufw delete allow 22

# Allow SSH only from Tailscale network
sudo ufw allow from 100.64.0.0/10 to any port 22

Or iptables:

# Drop all SSH from public
sudo iptables -A INPUT -p tcp --dport 22 -i eth0 -j DROP

# Allow SSH from Tailscale interface
sudo iptables -A INPUT -p tcp --dport 22 -i tailscale0 -j ACCEPT

Step 5: Test From another device:

ssh user@100.101.102.104
# Or
ssh user@server-name.tail<xxx>.ts.net

Result: SSH completely secured. Cannot be reached from public internet.

Samba (SMB) Configuration via Tailscale

Step 1: Install Samba

sudo apt install samba

Step 2: Create Share

# Create directory
sudo mkdir -p /srv/shares/documents
sudo chown -R andrew:andrew /srv/shares/documents

# Configure Samba
sudo nano /etc/samba/smb.conf

Add share definition:

[documents]
   path = /srv/shares/documents
   browseable = yes
   read only = no
   create mask = 0644
   directory mask = 0755
   valid users = andrew

Step 3: Set Samba Password

sudo smbpasswd -a andrew

Step 4: Configure Samba to Listen on Tailscale Interface Only

sudo nano /etc/samba/smb.conf

In [global] section:

[global]
   interfaces = 100.101.102.104 tailscale0
   bind interfaces only = yes

Step 5: Restart Samba

sudo systemctl restart smbd

Step 6: Configure Firewall

# Allow Samba only from Tailscale
sudo ufw allow from 100.64.0.0/10 to any port 445
sudo ufw allow from 100.64.0.0/10 to any port 139

Step 7: Access from Windows

\\100.101.102.104\documents
\\linux-server.tail<xxx>.ts.net\documents

Subnet Router Configuration

Use Case: Make an entire network (192.168.1.0/24) accessible via Tailscale.

Step 1: Enable IP Forwarding

sudo nano /etc/sysctl.conf

Add or uncomment:

net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

Apply:

sudo sysctl -p

Step 2: Start Tailscale with Subnet Advertising

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

Step 3: Approve Routes

1. Go to Tailscale admin console
2. Navigate to your device
3. Click "Edit route settings"
4. Enable advertised routes

Step 4: Configure NAT (if needed)

# Add iptables NAT rule
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Make persistent:

sudo apt install iptables-persistent
sudo netfilter-persistent save

Result: Devices on your Tailscale network can now access 192.168.1.x addresses.

Exit Node Configuration

Step 1: Enable as Exit Node

sudo tailscale up --advertise-exit-node

Step 2: Approve in Admin Console

1. Admin console → Machine settings
2. Enable "Exit node"

Step 3: Enable NAT

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo netfilter-persistent save

Step 4: Use from Client

# From any other Tailscale device
tailscale up --exit-node=100.101.102.104

All internet traffic now routes through this device.

Docker Integration

Run Container with Tailscale:

Method 1: Sidecar Container

version: '3'
services:
  app:
    image: my-app:latest
    network_mode: service:tailscale
    depends_on:
      - tailscale
  
  tailscale:
    image: tailscale/tailscale:latest
    environment:
      - TS_AUTHKEY=${TS_AUTHKEY}
      - TS_STATE_DIR=/var/lib/tailscale
    volumes:
      - tailscale-state:/var/lib/tailscale
      - /dev/net/tun:/dev/net/tun
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    command: tailscaled

volumes:
  tailscale-state:

Method 2: Host Network Mode

version: '3'
services:
  app:
    image: my-app:latest
    network_mode: host
    # App can bind to Tailscale IP directly

My Personal Configuration

Infrastructure Overview:

• 1 Windows Server (home)
• 5 Linux VPS instances (OVH, Hetzner)
• 2 Raspberry Pis (home lab)
• 3 workstations (Windows laptops)
• 2 mobile devices

Tailscale ACL Configuration:

{
  "acls": [
    {
      "action": "accept",
      "src": ["andrew@ajolnet.com"],
      "dst": ["*:*"]
    },
    {
      "action": "accept",
      "src": ["tag:servers"],
      "dst": ["tag:servers:*"]
    }
  ],
  "tagOwners": {
    "tag:servers": ["andrew@ajolnet.com"]
  }
}

SSH Configuration:

• All servers listen only on Tailscale interfaces
• SSH key authentication only
• No password auth
• Root login disabled
• Fail2ban monitoring Tailscale interface

File Sharing:

• Windows Server SMB shares (family photos, documents)
• Linux Samba shares (project files, backups)
• All listening only on Tailscale

Backup Strategy:

# Cron job on VPS
0 2 * * * rsync -avz --delete /var/www/ andrew@100.101.102.50:/backups/vps-blog/

Remote Access:

• RDP to Windows Server from anywhere
• SSH to all VPS instances
• File access from mobile devices
• Home Assistant accessible remotely

Result: Zero exposed ports on any system. Zero VPN servers to maintain. Perfect security posture with minimal management overhead.

Part 4: The Company - Tailscale Inc.

Company History and Leadership

Founded: 2019

Founders:

• Avery Pennarun - Co-founder, former Google engineer
• Brad Fitzpatrick - Co-founder, creator of memcached and LiveJournal

Key Personnel:

• Avery Pennarun - CEO
• David Crawshaw - CTO, former Google Go team
• Brad Fitzpatrick - Board member, significant technical contributions
• Kristoffer Dalby - Lead developer of Headscale (open-source coordination server)

Company Size (2025):

• ~150 employees
• Distributed/remote-first company
• Engineering headquarters: Toronto, Canada
• U.S. presence: San Francisco, New York

Funding and Valuation

Total Funding: $116.4 million

Funding Rounds:

Series A (May 2020): $12 million

• Lead: Accel
• Valuation: ~$45 million

Series B (April 2021): $100 million

• Lead: Insight Partners, CRV
• Valuation: ~$1 billion (unicorn status)
• Participated: Accel, CRV, Uncork Capital

Seed Round (2019): $3.4 million

• Lead: Accel
• Participated: Heavybit, others

Investors:

• Accel (lead investor, multiple rounds)
• CRV (Constant Relativity Ventures)
• Insight Partners
• Heavybit Industries
• Uncork Capital
• Adobe Fund
• Various angel investors

Note: Tailscale is private (not publicly traded). Valuation estimates based on last funding round.

Business Model and Pricing

Target Markets:

1. Individual developers and enthusiasts
2. Small teams (2-50 people)
3. Mid-market enterprises (50-500 employees)
4. Large enterprises (500+ employees)

Pricing Tiers (as of 2025):

Personal (Free)

Cost: $0/month Includes:

• Up to 3 users
• 100 devices
• 1 subnet router
• Basic ACLs
• Community support

Perfect For:

• Personal use
• Home lab
• Small projects
• Developers

My Use: I’m on the Personal plan. It covers all my needs (8 devices, personal use).

Personal Pro ($6/month per user)

Includes everything in Personal, plus:

• Unlimited devices
• Priority support
• Custom domains (MagicDNS)
• Advanced ACLs

Team Starter ($5/user/month, min 10 users)

Business tier starting point:

• Everything in Personal Pro
• Shared admin console
• Email support
• SSO integration (Google Workspace, Microsoft)

Enterprise (Custom pricing)

For organizations with:

• Advanced SSO requirements (Okta, Azure AD, custom SAML)
• Custom SLA requirements
• Dedicated support
• SCIM provisioning
• Audit logging
• Network flow logs
• Custom contracts

Typical Pricing: $15-30/user/month depending on features.

Note: Pricing is remarkably affordable compared to traditional VPN solutions (which often cost $50-100+/user/month for enterprise).

Open Source and Headscale

Tailscale Client Code:

• Fully open source (BSD 3-Clause License)
• Available on GitHub: tailscale/tailscale
• Can be audited, modified, contributed to
• Community contributions welcomed

Headscale:

• Open-source coordination server (Tailscale-compatible)
• Created by Juan Font (independent developer)
• Now officially supported by Tailscale Inc.
• Allows self-hosting of coordination server
• GitHub: juanfont/headscale

What This Means:

• You can self-host entire Tailscale infrastructure if desired
• No lock-in to Tailscale’s cloud services
• Open protocol (can be reimplemented)
• Community can verify security claims

Why I Appreciate This: Tailscale could have been completely closed-source and proprietary. Instead, they’ve open-sourced everything except the coordination server (and even that has an open alternative). This demonstrates good faith and commitment to user freedom.

Technical Infrastructure

Coordination Servers:

• Globally distributed (AWS, GCP)
• Low-latency regions worldwide
• 99.9%+ uptime (personal observation: never experienced outage)
• GDPR compliant (data residency options)

DERP Relay Network:

• 20+ global locations (2025)
• Growing constantly
• Sub-50ms latency for most users
• Encrypted relay (cannot read traffic)

Data Privacy:

• Coordination server sees: device public keys, users, ACLs
• Coordination server does NOT see: actual traffic, file contents, communications
• All data encrypted end-to-end
• Tailscale cannot decrypt your traffic

Security Audits:

• Regular third-party security audits
• Bug bounty program
• Responsible disclosure policy
• Security advisories published transparently

Customer Base

Notable Users (Public):

• GitLab - Uses Tailscale for internal infrastructure
• Cruise - Self-driving car company (vehicle connectivity)
• Oxide Computer - Infrastructure company
• Fly.io - Application hosting platform
• Various Fortune 500 companies (mostly confidential)

User Statistics (2025 estimates):

• 1.5+ million devices on Tailscale networks
• 50,000+ organizations
• Growing 10-15% month-over-month
• Strong developer community

Competitive Landscape

Direct Competitors:

ZeroTier:

• Similar mesh VPN approach
• Older (founded 2011)
• More complex configuration
• Open-source server available

Nebula (by Slack/Salesforce):

• Open-source mesh VPN
• More DIY (no hosted coordination)
• Used by Slack internally

Netmaker:

• WireGuard-based like Tailscale
• Self-hosted focus
• More DevOps-oriented

Traditional VPN Solutions:

• OpenVPN (complex setup, central server)
• Cisco AnyConnect (enterprise, expensive)
• Palo Alto GlobalProtect (enterprise, expensive)
• NordVPN, ExpressVPN (consumer privacy, different use case)

Why Tailscale Wins (My Opinion):

1. Easiest setup (minutes vs. hours/days)
2. Best performance (direct connections, WireGuard speed)
3. Free tier is generous (perfect for personal use)
4. Open-source client (auditable, trustworthy)
5. Active development (new features monthly)
6. Excellent documentation
7. Responsive support (even on free tier)

Ecosystem and Integrations

Official Integrations:

• Kubernetes Operator - Manage k8s services via Tailscale
• Docker - Containerized deployments
• Terraform Provider - Infrastructure as code
• GitHub Actions - CI/CD integration
• AWS, Azure, GCP - Cloud provider plugins

Third-Party Integrations:

• Home Assistant add-on
• Synology NAS package
• QNAP package
• Ubiquiti UniFi integration
• pfSense/OPNsense packages

API:

• Full REST API
• Manage devices programmatically
• ACL automation
• Webhook notifications

Part 5: Critical Analysis - Strengths and Weaknesses

Strengths

1. Exceptional Ease of Use

• Installation: 2 minutes
• Configuration: Mostly automatic
• Learning curve: Minimal
• This is Tailscale’s killer feature

2. Outstanding Performance

• WireGuard speed (near-native)
• Direct connections (no central bottleneck)
• Low latency (<10ms typical overhead)
• Works well on mobile networks

3. Security by Default

• Zero-trust architecture
• No exposed ports
• WireGuard encryption
• Regular security audits

4. Cost-Effective

• Free tier is extremely generous
• Paid tiers affordable vs. alternatives
• No hidden costs
• Predictable pricing

5. Cross-Platform Excellence

• Works identically on all platforms
• Mobile apps are first-class
• Consistent experience everywhere

6. Reliability

• In 2+ years of use, zero unexpected downtime
• Automatic failover (direct → DERP)
• Handles network changes gracefully
• “It just works” reliability

7. Active Development

• New features every few months
• Bug fixes are rapid
• Community feedback incorporated
• Transparent roadmap

8. Excellent Documentation

• Comprehensive official docs
• Active community forum
• Blog posts explaining features deeply
• Troubleshooting guides

Weaknesses and Concerns

1. Centralized Coordination Server (The Big One)

This is my primary concern with Tailscale.

The Problem:

• All device authentication goes through Tailscale’s cloud
• Device key distribution requires Tailscale servers
• If Tailscale goes down, new devices can’t join
• If Tailscale is acquired/changes policy, users are affected
• Company failure = network failure

Mitigations:

• Existing connections continue working (peer-to-peer)
• Headscale allows self-hosting
• Client is open-source (could be forked)
• Company seems financially stable

My Take: This is the price of convenience. Tailscale makes network coordination trivial by centralizing it. The alternative (Nebula, WireGuard manual) requires much more expertise.

For my use case (personal infrastructure), I accept this trade-off. For critical enterprise infrastructure, I’d consider Headscale self-hosting.

2. Limited Customization (vs. Raw WireGuard)

WireGuard experts can do things Tailscale doesn’t support:

• Custom cryptographic parameters
• Unusual network topologies
• Integration with exotic systems

For 99% of users: Tailscale’s opinionated approach is a feature, not a bug.

3. Mobile Battery Drain

On mobile devices, Tailscale can consume 2-5% battery per day when connected.

Mitigations:

• Use “On Demand” mode (connect only when needed)
• Disable when not actively using
• Trade-off: convenience vs. battery

4. DERP Relay Dependency

When direct connections fail (~20% of time), you rely on Tailscale’s DERP relays.

Concerns:

• Adds latency
• Relies on Tailscale infrastructure
• Bandwidth passes through their servers (encrypted, but still)

Mitigations:

• Most connections are direct
• DERP only when necessary
• Can run your own DERP servers (advanced)

5. Limited Network Segmentation (Compared to Enterprise VPN)

Traditional VPNs offer VLANs, multiple subnets, complex routing.

Tailscale’s ACLs are powerful but not infinitely flexible.

For Most Users: Tailscale’s model is simpler and sufficient.

6. Learning Curve for ACLs

While basic use is simple, advanced ACL configuration can be complex.

Example ACL:

{
  "acls": [
    {
      "action": "accept",
      "src": ["group:eng"],
      "dst": ["tag:prod:22"]
    }
  ],
  "groups": {
    "group:eng": ["user1@example.com", "user2@example.com"]
  },
  "tagOwners": {
    "tag:prod": ["group:admin"]
  }
}

This is powerful but requires understanding.

7. Vendor Lock-In (Partial)

While client is open-source:

• Coordination protocol is proprietary
• Migrating away requires reconfiguration
• Network effect (everyone on Tailscale)

Mitigation:

• Headscale compatibility
• Open client means worst-case you can fork
• WireGuard underneath means underlying tech is portable

Comparison: Tailscale vs. Alternatives

Tailscale vs. OpenVPN

When to use OpenVPN:

• Need open-source server
• Already deployed and working
• Specific compliance requirements

When to use Tailscale:

• Starting fresh
• Want minimal maintenance
• Need mesh networking
• Value simplicity

Tailscale vs. ZeroTier

When to use ZeroTier:

• Established ecosystem
• Specific feature requirements
• Already familiar with it

When to use Tailscale:

• Starting new
• Want WireGuard performance
• Prefer modern UI

Tailscale vs. Self-Managed WireGuard

When to use Manual WireGuard:

• Maximum control needed
• Custom network topology
• Learning exercise
• Distrust of third parties

When to use Tailscale:

• Value time over control
• Want automatic management
• Need mobile support
• Prefer maintained solution

Part 6: Advanced Topics and Future

Headscale: Self-Hosted Coordination

For those concerned about Tailscale’s centralized coordination server, Headscale offers a solution.

What Headscale Is:

• Open-source implementation of Tailscale coordination server
• Compatible with Tailscale clients
• Self-hostable on your infrastructure
• Maintained by community (officially supported by Tailscale Inc.)

Setup (Basic):

# Install Headscale
wget https://github.com/juanfont/headscale/releases/latest/download/headscale_linux_amd64
sudo mv headscale_linux_amd64 /usr/local/bin/headscale
sudo chmod +x /usr/local/bin/headscale

# Create config
headscale config

# Start server
headscale serve

# Create user
headscale users create andrew

# Generate auth key
headscale preauthkeys create --user andrew

# On client, point to your server
tailscale up --login-server=https://headscale.yourdomain.com

Advantages of Headscale:

• Complete control over coordination
• No dependency on Tailscale cloud
• Can run on your infrastructure
• Open-source and auditable

Disadvantages:

• You manage the infrastructure
• No official support (community only)
• Feature parity may lag Tailscale
• Requires more expertise

My Take: For personal use, Tailscale’s coordination server is fine. For critical infrastructure or paranoid security requirements, Headscale is excellent.

Enterprise Features

SAML/OIDC SSO: Integrate with enterprise identity providers:

• Okta
• Azure Active Directory
• Google Workspace
• JumpCloud
• Auth0
• Custom SAML providers

SCIM Provisioning: Automatic user provisioning/deprovisioning from identity provider.

Audit Logs: Complete logging of:

• Device authorizations
• User authentications
• ACL changes
• Connection attempts
• Administrative actions

Network Flow Logs: Detailed traffic flow information for compliance and monitoring.

Custom SLAs: Guaranteed uptime and support response times.

Future Developments

Based on Roadmap and Community Discussions:

1. IPv6 Support Improvements Already works, but native IPv6 addressing planned.

2. BGP Integration For advanced routing scenarios and datacenter integration.

3. Enhanced Subnet Routing More flexible routing policies and performance improvements.

4. Improved Windows Integration Better integration with Windows networking stack and Active Directory.

5. Kubernetes Enhancements Deeper integration with service mesh concepts.

6. On-Premises Deployment Options Official support for entirely on-prem deployments (like Headscale, but official).

7. Enhanced Mobile Features Better battery optimization, per-app routing, split tunneling.

The Future of Zero-Trust Networking

Tailscale represents a paradigm shift:

Old Model (Perimeter Security):

[Corporate Network]
      ↑
   Firewall
      ↑
[Untrusted Internet]

Inside = trusted, outside = untrusted.

New Model (Zero-Trust):

[Device] →(auth)→ [Service]
   ↓
Identity-based access

Nothing is trusted by default; every connection verified.

Why This Matters:

1. Remote Work: COVID-19 proved remote work is permanent. Traditional VPNs are terrible for this. Zero-trust mesh networks are natural fit.

2. Cloud/Multi-Cloud: Services span AWS, Azure, GCP, on-prem. Traditional networks can’t handle this. Mesh networks connect everything.

3. Security: Perimeter-based security is dead. Breaches assume compromised internal network. Zero-trust limits blast radius.

4. Simplicity: Managing traditional networks is complex. Zero-trust with Tailscale is simple.

Prediction: In 5-10 years, mesh networking with zero-trust principles will be standard. Tailscale is ahead of this curve.

Conclusion: Why Tailscale Matters

For Me Personally

Tailscale has transformed how I manage infrastructure:

Before Tailscale:

• Maintained OpenVPN server (frequent breakage)
• Exposed SSH ports (constant attack logs)
• Complex firewall rules (difficult to maintain)
• VPN didn’t work on some networks
• Mobile access was painful

After Tailscale:

• Zero maintenance (software updates only)
• Zero exposed ports (nothing to attack)
• Simple access control (ACLs)
• Works everywhere (phone, laptop, anywhere)
• Mobile access is seamless

The Result: I spend less time on networking and more time on actual work. This is the highest compliment I can give infrastructure software.

For the Industry

Tailscale demonstrates:

1. Security and usability are not opposites - Tailscale is both more secure and easier than alternatives
2. Open-source can succeed commercially - Open client, proprietary coordination, thriving business
3. Modern protocols matter - WireGuard’s simplicity enables Tailscale’s elegance
4. Zero-trust is practical - Not just theory; actually deployable at scale

The One Caveat: Centralization

I must acknowledge the elephant in the room: Tailscale’s coordination server is centralized.

This means:

• Trust in Tailscale Inc. (the company)
• Dependency on their infrastructure
• Potential for service disruption
• Vendor relationship

For most users, including me, this is acceptable because:

1. Company seems stable and well-funded
2. Open-source client reduces risk
3. Headscale provides escape hatch
4. Convenience outweighs theoretical risks

But it is a trade-off. Pure WireGuard or Nebula offer more independence at the cost of complexity.

My position: For personal and small business use, Tailscale’s trade-offs are worth it. For critical national infrastructure or paranoid security requirements, consider Headscale or fully self-managed solutions.

Final Recommendation

You should use Tailscale if:

• You manage multiple systems (servers, VPS, home lab)
• You value security (exposed ports bad)
• You value convenience (setup in minutes)
• You want reliable remote access
• You’re tired of VPN maintenance

You should consider alternatives if:

• You absolutely cannot depend on any third party
• You need exotic network configurations
• You have very specific compliance requirements
• You have strong opinions on protocol details

For the vast majority of users, Tailscale is the right choice.

My Use Case: A Love Letter

I write this not as paid promotion (I use the free tier), but as genuine advocacy.

Tailscale solved problems I didn’t know I had:

• SSH that actually works from anywhere
• File access without cloud storage costs
• Remote desktop without security nightmares
• Infrastructure that “just works”

It removed friction I had accepted as necessary:

• VPN connection rituals
• Port forwarding gymnastics
• Firewall rule archaeology
• Network troubleshooting

Most importantly: It lets me focus on my work instead of my networking infrastructure.

That’s what great infrastructure software does. It fades into the background, working reliably, so you can focus on what matters.

Tailscale achieves this better than any networking solution I’ve used in 15 years of IT work.

Getting Started

If I’ve convinced you to try Tailscale:

Step 1: Visit https://tailscale.com

Step 2: Download for your OS

Step 3: Install and authenticate

Step 4: Add a second device

Step 5: ping device-name.tail<xxx>.ts.net

You’re done. You now have a secure mesh network.

Next Steps:

• Configure SSH to listen only on Tailscale
• Set up a subnet router for your home network
• Try using your home server as exit node
• Explore ACLs for access control

Welcome to the future of networking.

Appendix: Quick Reference

Common Commands

# Status and information
tailscale status          # Show connected devices
tailscale ip              # Show your IPs
tailscale netcheck        # Test network connectivity
tailscale ping device     # Ping another device

# Connection management
tailscale up              # Connect to network
tailscale down            # Disconnect from network
tailscale up --exit-node=<ip>  # Route through exit node
tailscale up --exit-node=""    # Disable exit node

# Advanced
tailscale up --advertise-routes=<subnet>  # Subnet router
tailscale up --advertise-exit-node        # Exit node
tailscale up --accept-routes              # Accept subnet routes

# Administration
tailscale logout          # Log out device
tailscale set --hostname=<name>  # Set device name

Useful Links

Official:

• Homepage: https://tailscale.com
• Documentation: https://tailscale.com/kb
• Community Forum: https://forum.tailscale.com
• GitHub: https://github.com/tailscale/tailscale
• Status Page: https://status.tailscale.com

Headscale:

• GitHub: https://github.com/juanfont/headscale
• Documentation: https://headscale.net

Learning:

• Tailscale Blog: https://tailscale.com/blog
• WireGuard: https://www.wireguard.com

Configuration File Locations

Linux:

• Config: /etc/default/tailscaled
• State: /var/lib/tailscale/
• Logs: journalctl -u tailscaled

Windows:

• Config: %ProgramData%\Tailscale
• Logs: Event Viewer → Application → Tailscale

macOS:

• Config: /Library/Tailscale
• Logs: Console.app → Tailscale

Disclaimer: This guide represents personal experience and opinion. I am not >affiliated with Tailscale Inc. and receive no compensation for this content. >Technical details are accurate as of November 2025 but may change. Always refer to >official documentation for current information.

Last Updated: November 18, 2025