Tailscale builds WireGuard tunnels between your VMs and prefers a direct peer-to-peer path, using STUN and NAT hole-punching before touching any relay. When direct establishment fails, traffic falls back to company-operated DERP relays with no error and no visible change in connectivity. On a multi-region Azure mesh, that silence is the problem: relayed traffic pays extra latency and possibly egress cost, and the fallback hides the blocked path that caused it.
Where does your traffic go when direct peering fails?
When Tailscale cannot open a direct path between two peers, the traffic goes through DERP, the Designated Encrypted Relay for Packets, on relay servers Tailscale operates. According to the Tailscale overview on Wikipedia, the system combines WireGuard-based peer-to-peer or relayed VPN communication with a hosted management service, and DERP is the documented fallback when a direct connection cannot be established. Two things follow from that design. First, the relay is not a degraded mode the user is told about; the tunnel works either way. Second, ‘my VMs can reach each other’ tells you nothing about which path the bytes took.
That distinction matters more now than it did when Tailscale was a homelab accessory. The company is currently marketing its mesh overlay as the connective tissue for multi-cloud and on-prem workloads, with Kubernetes and SaaS connectivity as headline use cases on tailscale.com, and it shipped stable release 1.98.9 on July 14, 2026, per Wikipedia’s release history. A $160 million Series C led by Accel in April 2025 (Wikipedia), with CRV, Insight Partners, Heavybit, and Uncork Capital participating, positions the product squarely as production infrastructure. Production infrastructure gets held to production standards: known latency envelopes, known cost per gigabyte, known failure modes. A fallback path that fires silently meets none of those by default.
The uncomfortable part is that DERP fallback is doing exactly what it was designed to do. It papers over hostile network conditions so the overlay “just works.” On a home network behind a consumer router, that is a feature. On an Azure VM mesh where the blocked path is your own NSG rule, it is a misconfiguration wearing a working connection as camouflage.
How does Tailscale try to connect directly first?
Tailscale attempts direct peering through classic NAT traversal: STUN to discover the public endpoint, hole-punching to open the path, and port-forwarding requests via UPnP IGD, NAT-PMP, or PCP where those protocols exist. That ordering is documented in the Wikipedia entry and corroborated by XDA’s walkthrough of the architecture, which describes a central control server handling peer discovery and public-key exchange while the encrypted tunnels themselves are created only between the user’s own devices. The control plane sees metadata; the data plane is yours.
Two design choices in that stack deserve attention from anyone deploying to cloud VMs. The first is addressing: Tailscale assigns clients IPv4 addresses in carrier-grade NAT reserved space, chosen specifically to avoid colliding with existing networks (Wikipedia). On Azure, where VNet address planning is already a knife fight between teams, an overlay range that cannot overlap with anything you own removes a whole category of routing accidents. The second is the port-forwarding trio. UPnP IGD, NAT-PMP, and PCP are how Tailscale asks a cooperative gateway to open an inbound mapping. Cloud gateways are not cooperative in this way. No amount of hole-punching helps if the security layer drops unsolicited UDP before the tunnel’s WireGuard handshake ever sees it.
That last point is the crux of the Azure problem, and it is worth being precise about what is and is not established. The mechanism is established: direct peering needs a workable UDP path between endpoints, and when the environment denies one, DERP is next. The Azure-specific claims circulating in ops circles, that default NSG rules block Tailscale’s listening port and that multi-region meshes therefore relay far more often than operators expect, appear in none of the public sources. Treat them as hypotheses to test on your own tailnet, not as documented behavior.
What triggers DERP fallback, and what does the relay actually see?
DERP fallback triggers when direct establishment fails, and the relay sees only encrypted WireGuard payload passing through. Both halves of that sentence come from XDA’s analysis, and both are consistently misread in different directions.
The first misread is treating fallback as rare. It is, in Tailscale’s design intent, the exception: the system tries STUN, hole-punching, and port forwarding first, and relays only when all of those fail (Wikipedia). But design intent is not a measurement. The sources reviewed here never quantify the direct-success rate on any network, let alone on cloud VMs behind managed NAT and layered security rules. If you want a number for your mesh, you will have to produce it yourself; nobody has published one for you to borrow.
The second misread is using ‘the relay only sees encrypted data’ as an answer to objections about the relay path. It answers the confidentiality objection. It says nothing about the two objections that actually bite on a multi-region Azure mesh: the latency added by an extra hop through relay infrastructure you do not control, and the egress you may be billed for when bytes that should have stayed on the Azure fabric leave it, bounce off a DERP server, and come back. Encrypted traffic still costs money by the gigabyte. The wire does not care that it cannot read the payload.
The relays themselves are open-source and self-hostable (XDA). That option matters for exactly the scenario this article is about: if a chunk of your mesh will relay no matter what you do, running a DERP server inside your own Azure footprint turns ‘relayed through Tailscale’s nearest PoP’ into ‘relayed through a VM whose region and egress bill you chose.‘
Why isn’t “it connects” good enough on a multi-region mesh?
Because the connection-type split is the metric, and it is the one nobody graphs. The practical question for an Azure operator is not whether Tailscale works but what fraction of peer pairs are talking direct versus relayed, and how that fraction shifts with NSG changes, region additions, and client upgrades. No public source publishes a direct-success rate, which means the baseline assumption in most deployments (‘it connects, and Tailscale prefers direct, so we’re probably direct’) rests on nothing.
Instrumenting this is not exotic. The open-source tailscaled daemon and tailscale CLI, which share a codebase across Linux, Windows, and macOS per the tailscale/tailscale repository, are the obvious place to start; verify which per-peer fields your version surfaces before you depend on them. Scraping that state on a schedule and graphing the direct-versus-relayed split per region pair gives you the signal the fallback was designed to suppress. A sudden drop in direct success after an NSG or route-table change is the alarm; a chronically low number for a specific region pair is the to-do item.
The reason this discipline matters more on Azure than on a home network is that the failure modes are self-inflicted and fixable. A consumer behind carrier-grade NAT cannot open a port on equipment they do not own. An Azure operator usually can: adjust the NSG, allow the UDP path, place a subnet router, or decide deliberately that this traffic class will relay and budget for it. Every one of those options is invisible until you measure which peers are relaying and why.
The table below condenses the decision. The mechanism rows are sourced; the Azure cost and latency rows are the ones you must fill in from your own measurements, because no reviewed source publishes them.
| Decision axis | Direct P2P path | DERP relay path |
|---|---|---|
| When it is used | Default intent; STUN, hole-punching, UPnP IGD / NAT-PMP / PCP tried first (Wikipedia) | Fallback only, when direct establishment fails (XDA) |
| Who sees the traffic | Endpoints only; control server handles discovery and key exchange, not payload (XDA) | Tailscale-operated relay, encrypted payload only (XDA) |
| Latency profile on Azure | Direct VM-to-VM within the fabric [unverified] | Extra hop via relay region; magnitude not published in reviewed sources [unverified] |
| Egress cost on Azure | VNet-local or peering rates [unverified] | Potential internet egress both directions if the relay sits off-fabric [unverified] |
| Failure signal | None needed; path is explicit | Silent; connectivity succeeds, path type changes |
| Operator control | Fixable via NSG / UDP path configuration [unverified] | Replaceable with self-hosted DERP |
Managed control plane, Headscale, or self-hosted DERP?
The managed control plane is the default and the right starting point for most teams; Headscale and self-hosted DERP exist for the teams that measure their mesh and dislike what the relay path implies. The control server’s job is narrow: peer discovery and public-key exchange, while tunnels form only between your own devices (XDA). Keeping that server managed means Tailscale owns the availability of the coordination layer, and your data plane remains peer-to-peer regardless.
Headscale is the open-source, self-hostable implementation of that control server (XDA). Headscale solves ‘I do not want a third party coordinating my mesh.’ It does not solve ‘my traffic is relaying,’ because relaying is a data-plane problem. Teams sometimes adopt Headscale for control-plane sovereignty and then discover the DERP fallback rate is unchanged, because the NSG rules and NAT geometry that forced the fallback are unchanged. Self-hosting the control plane and fixing the direct path are independent projects; only one of them moves your latency numbers.
Self-hosted DERP is the data-plane counterpart. The relay code is open-source (XDA), and standing one up inside your own Azure subscription converts relay traffic from an unknown-quantity dependency into infrastructure you can place, size, and bill-predict. The honest read: self-hosted DERP is a reasonable destination for a measured, chronic relay problem, and a premature one for an unmeasured mesh.
What can you not assume about Tailscale on Azure?
You cannot assume any Azure-specific operational fact, because the public record contains none. No NSG default behavior, no UDP port guidance, no DERP egress pricing, no multi-region Azure latency benchmarks, no subnet-peering configuration appeared in the reviewed material. The strongest limitation of the public record here is that everything written about Tailscale’s routing decision is written generically, and everything written about Azure networking is written without Tailscale in mind. The intersection, which is where your mesh lives, is undocumented in the sources available.
That gap does not make the angle wrong; it makes it a checklist. Before publishing, presenting, or budgeting around any claim about Tailscale on Azure, verify each of the following on your own subscription:
- Whether your NSG rules permit the UDP path Tailscale needs for direct peering. Confirm by observing per-peer connection type before and after a rule change.
- Your actual direct-success rate per region pair, scraped from client state over at least a week. No published baseline exists in the reviewed sources.
- Whether relayed flows between your regions incur internet egress charges, and at what rate [unverified]. Pull this from your bill’s meter categories, not from a blog post, including this one.
- The latency delta between direct and relayed paths for the same region pair. Measure it with the relay forced on and off; no benchmark in the reviewed sources covers Azure.
- Whether 1.98.9, the current stable release as of July 14, 2026 (Wikipedia), changes any of the above for your clients, since NAT-traversal behavior does shift between releases.
So when is DERP fallback acceptable, and when is it a bill?
DERP fallback is acceptable when you have measured it and chosen it, and it is a bill when you have not. The design intent is clear across every reviewed source: direct P2P is the common case Tailscale wants, and DERP is the exception it tolerates to keep the overlay working (Wikipedia, XDA). The operational reality on a multi-region Azure mesh is that the exception rate is unknown until you instrument it, and the fallback’s silence means nobody will tell you when it stops being exceptional.
The decision procedure is short. First, instrument the direct-versus-relayed split per region pair; the open-source repository is where the client and its tooling live, so confirm what your version exposes before relying on it. Second, for the traffic that will not go direct, fix the path if the fix is cheap, which on Azure usually means an NSG or UDP-allowance change whose specifics you must verify yourself [unverified]. Third, for the traffic that will not go direct and cannot be fixed cheaply, compare the cost of relaying through Tailscale’s DERP, relaying through a self-hosted DERP inside your own footprint, and bypassing the overlay for those flows with subnet routing or VNet peering. Then write the answer down, because the next NSG change will silently move the numbers again.
What this article cannot tell you is any of the Azure-specific magnitudes, because no reviewed source publishes them. Anyone who quotes you a direct-success rate, an NSG default, or an egress figure for Tailscale-on-Azure without showing the measurement is doing the thing the fallback does: hiding an untested path behind a working answer.
Frequently Asked Questions
Does Tailscale 1.98.9 change how Azure NSGs handle UDP 41641?
The release notes for version 1.98.9 do not list any modifications to the UDP port requirements or NAT traversal logic. Azure operators must continue to verify that their Network Security Groups permit the specific UDP ports used by the WireGuard handshake and DERP fallback, as the release does not alter the underlying protocol behavior.
How does self-hosted DERP compare to the managed control plane?
Self-hosted DERP replaces the data-plane relay infrastructure, allowing teams to keep traffic within their own Azure footprint to control latency and egress costs. This is distinct from Headscale, which only replaces the control plane for peer discovery. Running a self-hosted relay does not automatically fix a low direct-success rate if the underlying NSG rules remain blocking the direct path.
What is the baseline direct-success rate for multi-region Azure meshes?
No public benchmark or vendor report publishes a baseline direct-success rate for Tailscale on Azure. The research brief confirms that the direct-success rate is never quantified in available sources, meaning operators must scrape per-peer connection types from the tailscale CLI to determine their own mesh health.
Can subnet routers bypass the need for direct peering in Azure?
Yes, the Linux client can route traffic to networks behind itself by disabling SNAT and routing directly to source IPs. This subnet-router behavior can keep Azure VNet-to-VNet flows on the fabric instead of bouncing them through an overlay relay, effectively bypassing the need for direct node-to-node peering for those specific flows.
