Understand direct connections and DERP

Tailscale always tries to build a direct UDP path between two peers. NATs and firewalls do not always let it.

How the direct path is built

Both devices learn each other’s candidate endpoints from the control plane: LAN addresses, public addresses, and ports discovered through STUN, a protocol that asks a public server “what address do you see me as?”. Then each device sends packets toward all of those candidates and keeps whichever path answers.

This is NAT traversal, and it succeeds surprisingly often, even when both devices sit behind home routers.

You can check what your current network allows:

tailscale netcheck

Report:
    * UDP: true
    * IPv4: yes, 93.44.120.15:41641
    * MappingVariesByDestIP: false
    * Nearest DERP: Frankfurt

UDP: true is the line you want. A network that blocks outbound UDP entirely forces everything through relays. MappingVariesByDestIP: false is good news too: your NAT behaves predictably, which makes a direct path much easier to find.

When DERP takes over

When a direct path fails, Tailscale relays the traffic through a DERP server. DERP stands for Designated Encrypted Relay for Packets. These servers run in regions around the world, and a connection often starts on DERP while the direct path is still being negotiated.

The relay sees connection metadata and moves bytes. It cannot decrypt the WireGuard payload, because your device encrypted those packets with a key the relay never had.

Here is what a relayed connection looks like:

tailscale ping strict-office-box

pong from strict-office-box (100.99.4.18) via DERP(fra) in 48ms

The connection works. Latency and throughput may be worse than a direct path, though. Hard NATs, symmetric NATs, and corporate firewalls that block UDP are the usual causes.

The honest promise

Write this down, because people get it wrong: Tailscale prefers direct peer connections, but it does not guarantee that every connection is direct.

A DERP path is not a failure, and it is not a security downgrade. It is the designed fallback that keeps the connection alive when the network refuses to cooperate. Later in the course we will see when a relayed path is worth improving and when it is fine to leave alone. Most of the time, for an SSH session, you will not even notice.