Tailscale on FreeBSD: Mesh VPN Review

Tailscale is a mesh VPN built on WireGuard that eliminates the configuration pain that has plagued VPN deployments for decades. There is no central VPN server. No port forwarding. No certificate management. No manual key exchange. You install Tailscale on each machine, authenticate, and every machine can reach every other machine directly over encrypted WireGuard tunnels. The coordination server handles key distribution, NAT traversal, and access control, while the data plane runs peer-to-peer with no traffic passing through Tailscale's infrastructure. On FreeBSD, Tailscale runs as a userspace daemon using the utun interface, integrates with the rc.d service framework, and provides the same mesh networking capabilities available on Linux, macOS, and Windows. This review covers Tailscale's architecture, FreeBSD-specific installation and configuration, ACLs, exit nodes, subnet routing, MagicDNS, and how it compares with manual WireGuard setups and ZeroTier.

What Tailscale Does

Tailscale is a control plane for WireGuard. WireGuard handles the encryption and tunneling. Tailscale handles everything else: identity, key distribution, NAT traversal, access control, and DNS.

Core capabilities:

Mesh networking -- every node can communicate directly with every other node. No hub-and-spoke topology. No single point of failure for data traffic.
NAT traversal -- Tailscale uses STUN, DERP relays, and various NAT hole-punching techniques to establish direct connections even when both endpoints are behind NAT. In most cases, traffic flows directly between peers without relay.
Identity-based networking -- access is tied to user identity (Google, Microsoft, GitHub, OIDC), not IP addresses or network location. A laptop at a coffee shop has the same access as one in the office.
ACLs (Access Control Lists) -- define which users and devices can reach which services. Written in a JSON-like policy language managed through the Tailscale admin console or GitOps.
Exit nodes -- route all internet traffic through a specific Tailscale node, functioning as a traditional VPN for privacy or geo-location purposes.
Subnet routing -- advertise local subnets to the Tailscale network, allowing access to devices that do not run Tailscale (printers, IoT devices, legacy servers).
MagicDNS -- automatic DNS for Tailscale hostnames. ssh myserver works without editing /etc/hosts or running a DNS server.
Taildrop -- encrypted file transfer between Tailscale nodes.
SSH -- Tailscale SSH replaces traditional SSH key management with Tailscale identity, including session recording and access control.

Tailscale is not a replacement for a site-to-site IPsec tunnel between data centers (though it can fill that role for smaller setups). Its sweet spot is connecting developers, servers, home labs, and remote workers into a single secure network without infrastructure complexity.

Installation on FreeBSD

Tailscale is available as a FreeBSD package.

Binary Package Installation

sh
pkg install tailscale

This installs the tailscaled daemon and the tailscale CLI tool.

Enable the daemon:

sh
sysrc tailscaled_enable="YES"
service tailscaled start

Authenticate

sh
tailscale up

This prints a URL. Open it in a browser, authenticate with your identity provider, and the machine joins your Tailscale network (called a "tailnet"). The process takes about 30 seconds.

After authentication, verify connectivity:

sh
tailscale status
tailscale ip

The status command shows all machines in your tailnet and their connection status. The ip command shows this machine's Tailscale IP address (in the 100.x.y.z CGNAT range).

Verify Connectivity

Ping another machine in your tailnet:

sh
tailscale ping other-machine

This shows whether the connection is direct (peer-to-peer) or relayed through a DERP server. Direct connections have lower latency.

Configuration on FreeBSD

Tailscale's configuration is minimal on the client side. Most policy is managed centrally through the Tailscale admin console or the ACL policy file.

Tailscaled Options

The daemon accepts flags via the rc.conf variable:

sh
sysrc tailscaled_args="--state=/var/db/tailscale/tailscaled.state --socket=/var/run/tailscale/tailscaled.sock"

The state file stores the machine's WireGuard keys and authentication state. Back it up if you want to preserve the machine's identity across reinstalls.

Advertise as an Exit Node

To make a FreeBSD server function as an exit node (route other devices' internet traffic through it):

sh
tailscale up --advertise-exit-node

Enable IP forwarding on the FreeBSD host:

sh
sysrc gateway_enable="YES"
sysctl net.inet.ip.forwarding=1

Other devices in the tailnet can then select this machine as their exit node through the Tailscale client.

Subnet Routing

Expose a local network to the tailnet without installing Tailscale on every device:

sh
tailscale up --advertise-routes=192.168.1.0/24,10.0.0.0/24

Enable IP forwarding as above. Then approve the routes in the Tailscale admin console. After approval, all devices in the tailnet can reach 192.168.1.0/24 and 10.0.0.0/24 through this FreeBSD node.

This is invaluable for accessing legacy infrastructure -- printers, switches, IPMI interfaces, and devices that cannot run Tailscale.

Accept Subnet Routes

To allow a FreeBSD machine to reach subnets advertised by other nodes:

sh
tailscale up --accept-routes

Access Control Lists (ACLs)

Tailscale ACLs define who can access what within the tailnet. They are written in a JSON-based policy language and managed through the admin console.

Example ACL Policy

sh
{
  "acls": [
    {
      "action": "accept",
      "src": ["group:developers"],
      "dst": ["tag:webserver:80,443"]
    },
    {
      "action": "accept",
      "src": ["group:sysadmins"],
      "dst": ["*:*"]
    },
    {
      "action": "accept",
      "src": ["tag:monitoring"],
      "dst": ["*:9090,9100"]
    }
  ],
  "tagOwners": {
    "tag:webserver": ["group:sysadmins"],
    "tag:monitoring": ["group:sysadmins"]
  },
  "groups": {
    "group:developers": ["user@example.com", "dev@example.com"],
    "group:sysadmins": ["admin@example.com"]
  }
}

This policy allows developers to reach web servers on ports 80 and 443, sysadmins to reach everything, and monitoring-tagged machines to scrape Prometheus metrics on all nodes. All other traffic is denied by default.

Tagging Machines

Tag a FreeBSD machine for ACL purposes:

sh
tailscale up --advertise-tags=tag:webserver

Tags are approved by tag owners defined in the ACL policy.

MagicDNS

MagicDNS provides automatic DNS resolution for Tailscale hostnames. When enabled, machines are reachable by their Tailscale hostname:

sh
ssh myserver
curl http://api-server:8080

No /etc/hosts editing. No DNS server configuration. MagicDNS is enabled by default in new tailnets.

On FreeBSD, MagicDNS modifies /etc/resolv.conf to point at a local DNS proxy run by tailscaled. If you use a custom DNS setup, you may need to configure split DNS:

sh
tailscale up --accept-dns=false

Then configure your local resolver to forward queries for the Tailscale domain (default tailnet-name.ts.net) to the Tailscale DNS proxy.

Tailscale SSH

Tailscale SSH replaces traditional SSH key management. Instead of distributing SSH keys, users authenticate via their Tailscale identity:

sh
tailscale up --ssh

On the FreeBSD server, this starts an SSH server managed by Tailscale. Access is controlled via ACLs:

sh
{
  "ssh": [
    {
      "action": "accept",
      "src": ["group:sysadmins"],
      "dst": ["tag:server"],
      "users": ["root", "admin"]
    },
    {
      "action": "accept",
      "src": ["group:developers"],
      "dst": ["tag:server"],
      "users": ["deploy"]
    }
  ]
}

Developers can SSH as the deploy user. Sysadmins can SSH as root or admin. No SSH keys to manage, rotate, or revoke.

Performance

Tailscale uses WireGuard for the data plane, so encryption performance matches WireGuard's. On a modern FreeBSD system:

Throughput: 1-3 Gbps between peers on a LAN (WireGuard's in-kernel performance is higher, but Tailscale's userspace implementation on FreeBSD is still fast).
Latency: sub-millisecond overhead for direct connections. DERP-relayed connections add the latency of the relay server round trip.
Connection establishment: direct connections are established in 1-5 seconds after initial authentication. Subsequent connections are near-instant as WireGuard maintains the tunnel.

Checking Connection Quality

sh
tailscale ping --c 10 other-machine
tailscale netcheck

The netcheck command tests connectivity to DERP relays and reports UDP connectivity, which is required for direct connections.

Tailscale vs Manual WireGuard

The core question: why use Tailscale when WireGuard is already available on FreeBSD?

Choose Tailscale when:

You have more than 3-4 machines. Manual WireGuard requires O(n^2) key exchange for full mesh.
You need NAT traversal. Manual WireGuard requires at least one endpoint with a public IP and static port forwarding.
You want identity-based access control instead of IP-based firewall rules.
You have non-technical users who need VPN access without configuration.
You want centralized management, audit logs, and device inventory.
You need MagicDNS and do not want to run a DNS server.

Choose manual WireGuard when:

You have a simple point-to-point or hub-and-spoke topology with 2-3 nodes.
You need maximum throughput (in-kernel WireGuard on FreeBSD is faster than Tailscale's userspace implementation).
You want zero external dependencies -- no coordination server, no account, no third-party trust.
You need the VPN to work in air-gapped environments with no internet access.
You want to avoid any third-party infrastructure in your network path, even for coordination.

Configuration Comparison

A 5-node full mesh with manual WireGuard requires: 5 config files, 10 peer entries per file (each node needs every other node's public key and endpoint), port forwarding on all nodes or a central relay, and manual key rotation. That is roughly 50 peer entries to maintain.

With Tailscale: install on 5 machines, run tailscale up on each, done. Keys are rotated automatically. NAT traversal works without configuration.

Tailscale vs ZeroTier

ZeroTier is another mesh VPN that competes directly with Tailscale:

Architecture -- both use a coordination server with peer-to-peer data plane. ZeroTier uses its own encryption protocol; Tailscale uses WireGuard.
FreeBSD support -- both have FreeBSD packages. Tailscale's FreeBSD support is more actively maintained.
Self-hosting -- ZeroTier's controller can be self-hosted. Tailscale offers Headscale, a community-maintained open-source coordination server.
Performance -- Tailscale's WireGuard-based encryption is faster than ZeroTier's custom protocol in most benchmarks.
ACLs -- Tailscale's ACL system is more granular and better documented.
Pricing -- both offer free tiers. Tailscale's free tier allows up to 100 devices. ZeroTier's free tier allows up to 25 devices.

For FreeBSD deployments, Tailscale is the stronger choice due to better FreeBSD support, WireGuard's performance advantage, and the more mature ACL system.

Headscale: Self-Hosted Coordination Server

If you do not want to depend on Tailscale's coordination server, Headscale is an open-source alternative:

sh
pkg install headscale

Headscale implements the Tailscale coordination protocol, allowing you to run your own control plane. Tailscale clients connect to your Headscale server instead of Tailscale's servers. This eliminates the third-party dependency while retaining Tailscale's client-side features.

Configure a FreeBSD Tailscale client to use Headscale:

sh
tailscale up --login-server https://headscale.example.com

Verdict

Tailscale is the easiest way to connect FreeBSD servers, workstations, and remote users into a secure mesh network. It removes the operational burden of VPN management -- key distribution, NAT traversal, endpoint configuration, DNS -- and replaces it with identity-based access control and automatic mesh routing. The WireGuard foundation ensures strong encryption and good performance.

For FreeBSD sysadmins managing multiple machines across different networks, Tailscale eliminates hours of WireGuard configuration and ongoing maintenance. The trade-off is dependency on Tailscale's coordination server (mitigated by Headscale for self-hosting). For simple point-to-point tunnels or maximum performance, manual WireGuard remains the better option.

Frequently Asked Questions

Does Tailscale work in FreeBSD jails?

Tailscale requires a TUN/TAP device, which is not available in standard jails. It works in VNET jails with the tun device passed through, or directly on the host system. For jail networking, use the host's Tailscale connection with subnet routing to expose jail networks.

Is Tailscale traffic routed through Tailscale's servers?

Data traffic is peer-to-peer in most cases. Tailscale's DERP relay servers are used only when direct connections fail (rare symmetric NAT configurations). The coordination server handles key exchange and configuration only -- it never sees your data traffic.

How do I use Tailscale for remote access to my FreeBSD home server?

Install Tailscale on both your home server and your laptop. Both join the same tailnet. You can then SSH, access web interfaces, and connect to services on your home server from anywhere, without port forwarding or dynamic DNS.

Can Tailscale replace my site-to-site VPN?

For small-to-medium deployments, yes. Use subnet routing on both sides to expose local networks. For high-throughput site-to-site links (multi-gigabit), manual WireGuard or IPsec may be more appropriate due to in-kernel performance.

What happens if Tailscale the company shuts down?

Existing connections continue to work as long as the coordination server is reachable. If Tailscale's servers go offline, new connections and key rotations fail. Headscale provides a self-hosted fallback. The Tailscale client is open source, and WireGuard configurations can be extracted manually.

How do I monitor Tailscale on FreeBSD?

Use tailscale status for a quick overview. For detailed diagnostics: tailscale debug and tailscale bugreport. Tailscale logs to syslog, visible at /var/log/messages or via journalctl if available.

Tailscale on FreeBSD: Mesh VPN Review