This episode dissects Tailscale's security model: end-to-end WireGuard encryption between peers, public and private key management, why traffic never passes through the control plane, the NAT traversal mechanism, the role of DERP relays, and its privacy implications.

After covering the features that make life easier, it's time to talk about security — the foundation that makes all those features trustworthy. The most important question: where does your data actually sit while flowing through the tailnet?
Episode 12 answers it: end-to-end encryption with WireGuard, automatic key management, and the architectural reasons why traffic never passes through the control plane. We also cover the NAT traversal mechanism, the role of DERP relays as a fallback, and the privacy implications of each layer.
All traffic in the tailnet is wrapped in a WireGuard tunnel. Encryption happens at the origin and is unlocked at the destination — no middle point sees plaintext. This applies to direct connections as well as connections through DERP relays, since a relay only forwards already-encrypted packets.
tailscale status
sudo tailscale debug prefs | grep -i keyThe combination of tailscale status and debug prefs shows your node keys registered with the control plane.
Tailscale automates what used to be manual in WireGuard:
sudo tailscale debug prefs | grep -i publicYou don't need to exchange keys manually between devices like with pure WireGuard — the control plane handles distributing public keys to every peer.
This is the most important architectural decision: the control plane only carries coordination metadata — public keys, endpoint addresses, configuration. Application traffic flows directly between nodes through the WireGuard tunnel. Even if a connection goes through a DERP relay, what passes is encrypted WireGuard packets, not raw data. That means neither the control plane nor a relay can read the contents of your communication.
When two nodes are behind NAT, Tailscale performs hole punching: each node opens an outbound connection to the internet, and the two directions are brought together. Once a direct connection is established, packets flow directly between nodes with no intermediary.
tailscale netcheckThe output of tailscale netcheck shows the NAT type of each endpoint and whether a direct connection is likely to succeed.
When NAT traversal fails — for example with strict symmetric NAT — traffic is routed through a DERP relay. It's important to understand: DERP does not decrypt traffic. It receives encrypted WireGuard packets from one node and forwards them to another. So even when the path goes through a relay, confidentiality is preserved end-to-end.
tailscale derptailscale derp lists the available relay regions along with their latency.
Tailscale's security model can be summarized in three layers:
1. Identity -> SSO + node authentication (episode 13)
2. Authorization -> ACLs and tags (episodes 6 and 14)
3. Encryption -> WireGuard end-to-end (this episode)All three must be filled in. Encryption alone isn't enough if ACLs are wide open, and ACLs alone aren't enough if authentication is weak.
tailscale status and review ACLs regularly.Tailscale's security model rests on one premise: data is encrypted end-to-end, and coordination is separated from traffic. NAT traversal prioritizes direct connections, DERP is only a fallback that stays encrypted, and privacy is preserved on every path.
Episode 12 strengthened your confidence in Tailscale's security model: you understand end-to-end WireGuard encryption, automated key management, the separation between control plane and data plane, and DERP's role in preserving confidentiality.
Key takeaways:
tailscale netcheck and tailscale derp for checking paths.In the next episode, episode 13, we'll cover authentication and SSO — logging in via Google, GitHub, Microsoft, or Okta with multi-factor authentication, plus auth keys, API keys, and Tailnet Lock to protect the tailnet from compromise.