Tailcat: Inside the Serverless, Accountless WireGuard Data Plane by Tailscale

Tailscale co-founder Brad Fitzpatrick released Tailcat, an open-source command-line utility and Go package that strips Tailscale down to its raw networking engine. The tool allows two machines to establish an encrypted, direct peer-to-peer connection through firewalls and NAT without logging into Tailscale, without running a coordination server like Headscale, and without requesting root permissions from the host operating system.

For years, developers have faced a trade-off when connecting two remote machines. A raw WireGuard tunnel requires a public IPv4 or IPv6 address and manual port forwarding. A full Tailscale deployment solves NAT traversal and key distribution, but ties both endpoints to an identity provider, a centralized control plane, and a virtual TUN device requiring administrative privileges. Tailcat eliminates the control plane entirely, operating as a standalone network pipe.

How the Architecture Works

Tailcat borrows its interface philosophy from netcat, the venerable UNIX networking tool. Rather than creating a virtual network adapter or modifying host routing tables, Tailcat runs entirely in userspace.

1. Address Encoding via CBOR

A standard Tailscale node receives its configuration and network map from an HTTPS control server. Tailcat replaces that continuous synchronization loop with a single self-contained string.

When a server starts, it derives an address with the prefix tc. The remaining payload consists of a base64-encoded CBOR (Concise Binary Object Representation) structure containing:

• The server’s 32-byte WireGuard public key.
• A list of designated DERP (Designated Encrypted Relay for Packets) servers used for initial rendezvous.

Because the address carries all connection metadata, the client needs no external directory or domain name resolution. Operators can also publish the string as a DNS TXT record for static discovery.

2. Rendezvous Protocol and DERP

Connecting two machines behind separate NAT routers requires an initial meeting point. Both endpoints open an outbound TLS connection on port 443 to a designated DERP server. Because this traffic appears as standard outbound HTTPS, local firewalls rarely block it.

The client sends a packet addressed to the server’s public key over the relay connection. Tailcat refers to this initial presence packet as a MEOW message. When the server validates the incoming key, it returns a matching confirmation.

3. Magicsock and NAT Traversal

Once the initial handshake succeeds over the relay, Tailscale’s magicsock layer attempts to upgrade the connection to a direct path:

• Both peers send STUN requests to discover their external public IP addresses and assigned NAT ports.
• Both endpoints send UDP probe packets directly to each other’s discovered endpoints.
• If both routers permit endpoint-independent or address-dependent mapping, the direct UDP tunnel opens, and traffic bypasses the relay completely.
• If one or both routers use symmetric NAT or strict enterprise firewall filters, the tunnel remains on the DERP relay. In this fallback mode, the relay only sees encrypted WireGuard frames; it cannot inspect the payload.

4. Userspace TCP Stack

Traditional VPN software requires creating a virtual TUN or TAP network interface, which demands root or administrator privileges on Linux, macOS, and Windows.

Tailcat bypasses the kernel network stack by embedding Google’s gVisor netstack library directly into the Go binary. When data arrives over the decrypted WireGuard layer, the embedded TCP stack parses packets and hands raw byte streams directly to standard input and output. The host operating system never sees virtual interfaces, IP address assignments, or routing table modifications.

Real-World Usage Patterns

Because Tailcat requires no accounts and no root access, it fits into environments where traditional VPN clients cannot run.

Ad-Hoc File Transfer Between Remote Servers

Transferring large files between two firewalled cloud servers often requires intermediate object storage or opening temporary SSH ports:

# On the receiving machine:
tailcat --listen | tar -xzvf -

# The command outputs the connection address:
# Server listening at: tc1q2w3e4r...

# On the sending machine:
tar -czvf - ./build-artifacts | tailcat tc1q2w3e4r...

Exposing an Internal Web Service for Quick Debugging

An engineer running a development server on localhost can bridge access to a remote teammate without registering a domain or setting up an ngrok tunnel:

# On the machine hosting the web service on port 8080:
tailcat --listen --forward-tcp 127.0.0.1:8080

# On the remote developer machine:
tailcat --local-port 8080 tc1q2w3e4r...

The remote developer can open http://localhost:8080 in their local browser. The connection traverses an end-to-end encrypted WireGuard tunnel, terminates inside Tailcat’s userspace stack, and forwards directly to the target port.

Publishing Static Addresses in DNS

Instead of copying long base64 strings across chat applications, operators can record the Tailcat string in a DNS TXT record:

_tailcat.backup.internal.example. 300 IN TXT "tc1q2w3e4r5t6y7u..."

Connecting clients can then resolve the record directly:

tailcat backup.internal.example < database-dump.sql

Self-Hosting and Operational Autonomy

By default, Tailcat can use public DERP relays maintained by Tailscale with strict bandwidth limits. However, users seeking complete operational independence can deploy their own DERP server using the open-source derper daemon:

# Run a private DERP relay on a VPS with a public IP:
go install tailscale.com/cmd/derper@latest
derper --hostname=relay.example.com --certmode=letsencrypt

Passing --derp-server=relay.example.com to Tailcat ensures that all discovery packets and relay fallbacks pass exclusively through infrastructure owned by the operator. Under this configuration, zero telemetry, metadata, or packets ever contact Tailscale infrastructure. This lightweight approach complements modern homelab stacks, fitting alongside tools like the Pangolin self-hosted AI gateway and network observability platforms like NetAlertX for private infrastructure monitoring.

Comparative Architecture

Limitations

Tailcat is not a drop-in replacement for a full corporate mesh network:

• No Centralized Access Policies: Because there is no control plane, revoking access requires rotating private keys and re-distributing addresses.
• Single Connection Scope: Tailcat connects one client to one server per invocation. It does not establish a persistent subnet router or full-mesh topology across hundreds of servers.
• Key Distribution Overhead: Security depends on protecting the generated address string. Anyone who obtains the string can attempt connection unless an explicit public-key whitelist is configured on the listener.

Sources

• Tailscale Blog: Tailcat Announcement
• GitHub Repository: Tailscale Open Source Monorepo
• Tailscale Documentation: How NAT Traversal Works
• Go Documentation: gVisor netstack package