How Mesh VPNs Traverse Firewalls Without Port Forwarding

Connecting a laptop at a coffee shop to a home server used to require a specific sequence of network chores. An administrator had to log into a router, assign a static IP address, and manually open UDP port 51820 to the public internet so a WireGuard tunnel could connect. If the server sat behind a carrier-grade NAT, or if the coffee shop blocked outbound VPN ports, the connection simply failed.

Today, overlay networks like Tailscale and NetBird connect those same devices in seconds with zero router configuration. As MakeUseOf noted in a recent evaluation, these tools allow users to forget the tunnel entirely. They build a peer-to-peer mesh over the WireGuard protocol, assigning each device an IP address in the 100.64.0.0/10 private subnet. The devices communicate directly, bypassing firewalls and Network Address Translation (NAT) boundaries without requiring a single forwarded port.[1][3]

The obstacle these tools overcome is the stateful firewall. When a device on a local network requests a webpage, the router's NAT creates a temporary mapping that allows the server's response to return through the same port. However, any incoming packet that does not match an existing outbound request is dropped. When two devices behind different NATs try to connect, both firewalls block the incoming traffic because neither has seen an outbound request to the other.[2]

Mesh VPNs solve this using a coordination server, which acts as a control plane that introduces the devices. As ServerSide notes, Tailscale is essentially WireGuard plus everything WireGuard deliberately leaves out. The coordination server handles key distribution and peer discovery, but it does not route the actual data. It simply tells each device where the other is located.

To find those locations, the clients use Session Traversal Utilities for NAT (STUN). A device sends a packet to a public STUN server, which replies with the public IP address and port the packet originated from. The device then shares this public mapping with the coordination server, which distributes it to the rest of the mesh network.[2]

With the public addresses known, the clients execute a technique called UDP hole punching. Both devices fire UDP packets at each other's public IP address simultaneously. The first packets are often dropped by the receiving firewall, but the act of sending them creates an outbound stateful mapping on the sender's router. When the next packets arrive, the router recognizes them as a response to the outbound traffic and lets them through. The hole is punched, and a direct WireGuard tunnel is established.[2]

This direct connection is highly reliable. Tailscale reports that internal metrics show success rates for direct NAT traversal well north of 90 percent in typical conditions. Once the tunnel is up, the coordination server steps out of the way. As ServerSpace explains, even if the management server goes down, existing connections keep working. Only new device registration and policy updates break.[2][3]

When firewalls are too strict, such as with symmetric NATs that randomize ports for every connection, hole punching fails. In these cases, the networks fall back to relay servers. Tailscale uses its own Designated Encrypted Relay for Packets (DERP) network, while NetBird uses Traversal Using Relays around NAT (TURN). The traffic remains end-to-end encrypted by WireGuard, but it takes an extra hop through a public server, which adds latency.

While the underlying mechanics are similar, the products diverge in their architecture and licensing. Tailscale uses an optimized userspace WireGuard implementation and keeps its coordination server proprietary, though a community project called Headscale allows for self-hosting. NetBird, which raised an 8.5 million euro Series A in early 2026, is fully open-source under the BSD-3 license and defaults to the Linux kernel WireGuard module when available.

The result is a network architecture that shifts security away from the physical perimeter. By abstracting away the complexity of NAT traversal and key management, these tools allow administrators to enforce access policies based on device identity rather than network location, turning any internet connection into a secure local LAN.[3]