Tailscale Features

Each device is reachable at: <hostname>.<tailnet-name>.ts.net

# Full qualified name
workstation.tail1234.ts.net

# Short name (within the same tailnet, MagicDNS resolves this)
workstation

Tailscale assigns each device an IP from the 100.64.0.0/10 range (RFC 6598 — Shared Address Space, originally allocated for CGNAT). This is a deliberate choice:

• Won't conflict with your LAN: Your office uses 10.0.0.0/8? Home uses 192.168.0.0/16? Neither overlaps with 100.64.0.0/10.
• Won't conflict with cloud VPCs: AWS, GCP, Azure VPCs typically use RFC 1918 space. No overlap.
• Stable across networks: Your device keeps its 100.x.y.z address whether you're on WiFi, cellular, ethernet, or roaming between them.

The one edge case: If your ISP uses CGNAT, you might see 100.64.x.x addresses on your WAN interface too. In practice this rarely causes issues because Tailscale's WireGuard interface has higher routing priority for Tailscale-specific IPs, but it's worth knowing if you're debugging routing.

Split DNS lets you configure the tailnet so that queries for specific domains are resolved by specific nameservers — routed through the tailnet.

// In Tailscale DNS settings:
{
  "dns": {
    "nameservers": ["100.100.100.100"],  // MagicDNS
    "routes": {
      "corp.example.com": ["10.0.0.53"],     // Corporate DNS for internal domains
      "staging.internal": ["10.1.0.53"]      // Staging environment DNS
    }
  }
}

Use case: You're at a coffee shop, but api.corp.example.com still resolves correctly because the query is routed through your tailnet to the corporate DNS server.

Tailscale distributes ACL rules to every node. Each node enforces the policy locally using packet filtering in the WireGuard layer. This means:

• No central bottleneck: ACL enforcement is distributed, not a single firewall in the path.
• Offline-capable: If the coordination server is temporarily unreachable, the last-pushed ACLs remain in effect.
• Fast updates: ACL changes are pushed to all nodes via the control plane connection (long-polling/WebSocket). Typical propagation: seconds.

Use case — accessing on-prem from anywhere: Put a subnet router in your office or datacenter. Now every tailnet member (working from home, a coffee shop, or traveling) can reach the entire office network. No traditional VPN concentrator, no port forwarding, no exposing services to the internet.

• HTTPS only: Tailscale terminates TLS with a Let's Encrypt certificate for *.ts.net
• Port limitations: Only ports 443, 8443, and 10000 are available for Funnel
• Use cases: Webhook receivers, demo deployments, sharing local dev server, CI/CD callbacks
• Not a CDN: Traffic goes through Tailscale's infrastructure to your device. Latency and bandwidth depend on your connection.

• Server side: Tailscale runs an SSH server embedded in the Tailscale daemon. When enabled, it intercepts SSH connections on the Tailscale interface.
• Authentication: Instead of SSH keys, the server verifies the connecting peer's Tailscale identity (which user, which device, which tags). This is enforced via ACLs.
• Authorization: SSH ACLs in the Tailscale policy define who can SSH into what, with what user:

{
  "ssh": [
    {
      "action": "accept",
      "src":    ["group:ops"],
      "dst":    ["tag:server"],
      "users":  ["root", "deploy"],
    },
    {
      "action": "accept",
      "src":    ["group:engineering"],
      "dst":    ["tag:server"],
      "users":  ["deploy"],  // No root for eng
    },
  ],
}

Integration with MDM: Device posture works best alongside mobile device management (MDM). Tailscale checks what the MDM reports about the device, and ACLs can reference posture attributes. This bridges the gap between network access control and endpoint management.