Understand direct connections and DERP

Tailscale tries to create a direct UDP path between peers. NATs and firewalls do not always allow that path.

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. Then they send packets toward all of them and keep whichever path works. 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 good news. A network that blocks outbound UDP entirely forces everything through relays.

When DERP takes over

When direct connectivity fails, Tailscale can relay the already encrypted traffic through a DERP server. DERP (Designated Encrypted Relay for Packets) servers run in regions around the world, and connections often start on DERP while the direct path is still being negotiated.

The relay sees connection metadata but cannot decrypt the WireGuard payload. Your packets were encrypted on your device with a key the relay never had.

tailscale ping strict-office-box

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

A relayed connection still works, although latency and throughput may be worse than a direct path. Hard NATs, symmetric NATs, and UDP-blocking corporate firewalls are the usual causes.

The honest promise

Write down the honest promise: 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 you will learn when a relayed path is worth improving and when it is fine to leave alone.