Azure NAT Gateway is a Hard NAT, which blocks the UDP hole-punching that Tailscale relies on for direct peer-to-peer paths. When direct connections fail, Tailscale automatically and silently falls back to its shared DERP relay servers—capping throughput and adding round-trip latency that most platform teams only discover after a bandwidth spike. Deploying a Tailscale Peer Relay to a public Azure subnet with an advertised UDP endpoint bypasses DERP entirely, but the topology is documented yet non-default, and the majority of Azure-hosted tailnets are running the fallback path without auditing it (Azure reference architecture · Tailscale Docs, Connection types · Tailscale Docs).
Why Azure NAT Gateway Is a Tailscale Throughput Trap
Tailscale’s official Azure reference architecture is explicit: “Azure NAT Gateway is a Hard NAT and will prevent direct connections causing connections to use DERP relay servers.” (Azure reference architecture · Tailscale Docs) This is not a misconfiguration or an edge case. It is a documented architectural constraint.
Hard NATs remap both the source address and port for every outbound UDP flow, which breaks the symmetric endpoint prediction that UDP hole-punching requires. When two Tailscale peers behind such NATs attempt to coordinate a direct path, the port mappings they advertise to each other do not match what the NAT actually allocates. The handshake fails. Tailscale then promotes the connection to its DERP relay mesh automatically, without logging the degradation at a level most operators monitor (Azure reference architecture · Tailscale Docs, Connection types · Tailscale Docs).
The DERP Ceiling: What Shared-Relay Throughput Actually Looks Like
Tailscale’s own documentation describes DERP servers as having “limited quality of service (QoS) characteristics,” making them “generally slower than direct connections and may offer lower maximum throughput.” (Connection types · Tailscale Docs) The fallback sequence—direct, then peer relay, then DERP—is automatic and silent.
Quantifying that slowdown is harder because Tailscale does not publish official throughput caps for shared DERP. GitHub issue #13133 documents a user reporting roughly 50 Mbps through Tailscale over DERP versus approximately 1 Gbps direct on the same VPS—a 20x reduction (DERP bandwidth limitation · Issue #13133 · tailscale/tailscale). That figure comes from a custom DERP deployment, not the shared public infrastructure, and community reports for shared public DERP typically cite lower figures in the 2–5 Mbps range (DERP bandwidth limitation · Issue #13133 · tailscale/tailscale).
Even if a Peer Relay is deployed, DERP may still win route selection. GitHub feature request #16028 notes that Tailscale currently weighs only latency when choosing between DERP and peer relay paths (FR: Combine metrics other than latency in weighing relay/DERP routes · Issue #16028 · tailscale/tailscale). A low-latency DERP route can therefore override a higher-bandwidth peer relay, leaving the relay unused in practice.
The Fix: Peer Relay Topology for Azure
The remediation is straightforward and documented: deploy a Peer Relay “to a public subnet in your virtual network, with a public IP address, and allow incoming UDP traffic to the relay port.” (Azure reference architecture · Tailscale Docs) The relay requires Tailscale v1.86 or later (Tailscale Peer Relays: Use your own devices as high-throughput relays (GA announcement)).
Because Azure NAT Gateway masks the private address, the relay cannot rely on automatic endpoint discovery. You must set --relay-server-static-endpoints to the VM’s public IP address and pair it with --relay-server-port to define the UDP listener port (Tailscale Peer Relays · Tailscale Docs). An NSG rule must permit inbound UDP on that port. No specific port number is prescribed in the documentation; the choice is operator-configurable (Tailscale Peer Relays · Tailscale Docs).
Peer Relays reached general availability on February 18, 2026, with lock contention improvements for higher throughput and multi-UDP socket traffic distribution (Tailscale Peer Relays: Use your own devices as high-throughput relays (GA announcement)). Tailscale did not publish numeric benchmarks comparing Peer Relay throughput to DERP in that announcement.
Frequently Asked Questions
How can I tell if my Azure tailnet is actually using DERP instead of direct connections?
Run tailscale status or tailscale netcheck on a peer. A connection listed as “relay” rather than “direct” indicates DERP fallback. tailscale ping -c 1 <peer> also reports the path type in its output.
Does Azure offer any alternative to NAT Gateway that preserves Tailscale direct paths?
Azure Load Balancer with outbound rules uses a different NAT model that, depending on configuration, may allow UDP hole-punching to succeed. Tailscale’s reference architecture specifically calls out NAT Gateway as the problematic variant; Standard Load Balancer outbound SNAT is not classified as Hard NAT in Tailscale’s documentation.
If a Peer Relay is deployed but DERP still wins on latency, what operational workarounds exist?
Place the Peer Relay in the same Azure region as the DERP server your peers would otherwise use, reducing the latency advantage DERP holds. You can also run tailscale netcheck to identify which DERP region is selected and co-locate the relay there. Until Tailscale implements bandwidth-aware route selection (issue #16028), physical proximity between relay and DERP is the only lever.
Are Peer Relays a paid feature or available on the free plan?
Peer Relays are available across Tailscale plans, including the free tier. The relay is simply a node on your tailnet running with relay flags enabled—it does not require a separate license or billing change.
What happens to in-flight connections if the Peer Relay goes down?
Tailscale falls back to the next available path—typically DERP—without dropping the connection outright. The switchover introduces a brief interruption as the new path is established, consistent with how Tailscale handles any path degradation event.