What is NAT?

Network Address Translation (NAT) is a technique used by routers and firewalls to allow multiple devices on a private network to share a single public IP address when accessing the internet. Your device has a private IP (like 192.168.1.50), but when you connect to a website, the router translates this to its public IP address and keeps track of which internal device made the request.

NAT was originally designed to conserve IPv4 addresses, but it creates a challenge for peer-to-peer connections: devices behind NAT cannot directly receive incoming connections from the internet because there's no way for external traffic to know which internal device to reach.

NAT in Different Environments

Not all NAT is created equal. The type of NAT you're behind can impact whether NetBird can establish a direct peer-to-peer connection or needs to fall back to relay servers.

Easy NAT

Most home routers use what's called Endpoint-Independent Mapping (EIM) or "Easy NAT". When your device sends a packet to any external address, the router assigns a public IP:port combination that remains consistent regardless of the destination.

How it works:

1. Your device at 192.168.1.50:12345 sends a UDP packet to Server A
2. Your router maps this to 203.0.113.10:54321
3. When your device sends another packet to Server B, the router uses the same public mapping 203.0.113.10:54321
4. Any server that knows this mapping can send packets back to your device

Why P2P usually works: Because the mapping is consistent, a STUN server can discover your public IP:port, share it with a peer, and that peer can send packets directly to you. The router sees return traffic and allows it through because it matches an existing mapping.

┌─────────────────┐     ┌──────────────┐     ┌─────────────────┐
│  Your Device    │────▶│  Home Router │────▶│    Internet     │
│ 192.168.1.50    │     │  (Easy NAT)  │     │                 │
│    :12345       │     │ 203.0.113.10 │     │                 │
└─────────────────┘     │    :54321    │     └─────────────────┘
                        └──────────────┘
                              │
                    Same port for all destinations

Restrictive NAT

Many enterprise firewalls and some ISP-grade routers use Endpoint-Dependent Mapping (EDM) or "Symmetric NAT". Here, the public IP:port mapping changes based on the destination.

How it works:

1. Your device at 10.0.5.100:12345 sends a UDP packet to Server A
2. The firewall maps this to 198.51.100.5:60001
3. When your device sends a packet to Server B, the firewall assigns a different mapping 198.51.100.5:60002
4. Packets from Server B cannot use the Server A mapping

Why P2P is harder: When a STUN server discovers your public IP:port, that mapping is only valid for traffic to/from the STUN server itself. When your peer tries to send packets to that address, the firewall may reject them or map them differently.

┌─────────────────┐     ┌──────────────────┐     ┌─────────────────┐
│  Your Device    │────▶│ Corporate        │────▶│    Internet     │
│  10.0.5.100     │     │ Firewall         │     │                 │
│    :12345       │     │ (Symmetric NAT)  │     │                 │
└─────────────────┘     │ 198.51.100.5     │     └─────────────────┘
                        │   :60001 → Srv A │
                        │   :60002 → Srv B │ Different port per destination
                        └──────────────────┘

Additional restrictions: Restrictive NAT firewalls often:

• Block UDP entirely or limit it to specific ports
• Require traffic to flow through HTTP/HTTPS proxies
• Perform deep packet inspection that interferes with tunneling protocols
• Have strict egress rules that only allow traffic to known destinations

Carrier-Grade NAT

Mobile carriers typically use Carrier-Grade NAT (CGNAT), which adds an extra layer of NAT between you and the internet. Your phone is behind NAT on the carrier's internal network, and that network is behind another NAT facing the internet.

The double-NAT problem:

┌─────────────┐     ┌───────────────┐     ┌───────────────┐     ┌──────────┐
│  Phone      │────▶│  Cell Tower   │────▶│  Carrier NAT  │────▶│ Internet │
│ 10.x.x.x    │     │   (NAT 1)     │     │   (NAT 2)     │     │          │
└─────────────┘     └───────────────┘     └───────────────┘     └──────────┘
                           │                      │
                    Private IP              Public IP
                    100.64.x.x             (Shared by many users)

Challenges for P2P:

• Two layers of NAT translation to traverse
• Carriers often use symmetric NAT at the CGNAT layer
• Public IP addresses are shared among thousands of users
• Mappings may have short timeouts (30-60 seconds)
• Network conditions change frequently as you move between towers

1:1 NAT

Cloud VMs and data center servers present a different scenario:

Public cloud (AWS, GCP, Azure):

• VMs often have private IPs with 1:1 NAT to a public IP (Elastic IP, etc.)
• This behaves like easy NAT for outbound connections
• Security groups control inbound access but don't affect NAT behavior
• P2P generally works well and usually don't any firewall updates

Private/On-premises data centers:

• May have no NAT at all (flat network with public or routed IPs)
• Or may be behind enterprise-grade firewalls with restrictive NAT
• Often have strict egress policies

NetBird Relay

When direct peer-to-peer connections aren't possible (usually due to NAT difficulties), NetBird uses relay servers to ensure connectivity. NetBird includes a custom-built relay system optimized specifically for its use case.

How the Relay Works

The NetBird relay is a lightweight server that forwards encrypted WireGuard traffic between peers when they cannot connect directly. Unlike traditional TURN servers, NetBird's relay uses a custom protocol designed for efficiency.

Transport protocols:

• QUIC: A modern UDP-based protocol with built-in encryption. This is the primary transport and offers lower latency.
• WebSocket: An HTTP-based protocol that works over TCP. This serves as a fallback when UDP is blocked, as it appears as standard HTTPS traffic to firewalls.

When a client connects to a relay server, it races both protocols simultaneously and uses whichever succeeds first. If QUIC (UDP) fails due to network restrictions, WebSocket (TCP) automatically takes over.

Relay Selection

When two peers need to communicate through a relay:

1. Both peers receive relay server information from the NetBird Management service
2. The Signal service helps peers negotiate which relay server to use
3. Both peers connect to the agreed-upon relay server
4. Traffic flows through the relay while remaining end-to-end encrypted

NetBird supports multiple relay server instances for high availability. If a relay server becomes unavailable, peers can switch to an alternative.

P2P vs. Relayed Connections

P2P (Peer-to-Peer) Connections

When NetBird establishes a P2P connection, traffic flows directly between peers with no intermediate servers:

┌──────────────┐                                    ┌──────────────┐
│    Peer A    │◀──────── Encrypted WireGuard ────▶│    Peer B    │
│  (Your PC)   │               Tunnel               │  (Server)    │
└──────────────┘                                    └──────────────┘

Advantages:

• Lower latency: Packets take the shortest network path
• Higher throughput: No relay server bottleneck
• Better reliability: Fewer points of failure
• Privacy: Traffic doesn't pass through any third-party infrastructure

Requirements:

• At least one peer must have "friendly" NAT or a public IP
• UDP traffic must be allowed by intermediate firewalls
• NAT mappings must be stable long enough for hole punching

Relayed Connections

When P2P fails, NetBird falls back to relay servers. Traffic is encrypted before leaving your device and remains encrypted through the relay:

┌──────────────┐         ┌───────────────┐         ┌──────────────┐
│    Peer A    │◀───────▶│ Relay Server  │◀───────▶│    Peer B    │
│  (Your PC)   │         │  (NetBird)    │         │  (Server)    │
└──────────────┘         └───────────────┘         └──────────────┘
                                │
                 Traffic is still WireGuard
                 encrypted end-to-end

When relayed connections occur:

• Both peers are behind symmetric NAT
• UDP is blocked but WebSocket over TCP is allowed
• Aggressive firewalls with deep packet inspection
• Extremely restrictive corporate networks

Trade-offs:

• Higher latency: Traffic must travel to and from the relay server
• Lower throughput: Relay server capacity is shared among users
• Geographic dependency: Latency depends on relay server location

Checking Your Connection Type

You can see whether your connections are P2P or relayed using the NetBird CLI:

netbird status --detail

Example output:

Peers detail:
 server-a.netbird.cloud:
  NetBird IP: 100.75.232.118/32
  Status: Connected
  -- detail --
  Connection type: P2P
  Direct: true
  ICE candidate (Local/Remote): host/srflx
  ICE candidate endpoints (Local/Remote): 192.168.1.50:51820/203.0.113.10:51820
  Relay server address: rels://streamline-es-mad1-0.relay.netbird.io:443
  Last connection update: 1 hour, 37 minutes ago
  Last WireGuard handshake: 1 minute, 5 seconds ago
  Transfer status (received/sent) 6.5 KiB/10.3 KiB
  Quantum resistance: false
  Networks: -
  Latency: 15.2ms

 server-b.netbird.cloud:
  NetBird IP: 100.75.226.48/32
  Status: Connected
  -- detail --
  Connection type: Relayed
  Direct: false
  ICE candidate (Local/Remote): relay/host
  ICE candidate endpoints (Local/Remote): 108.54.10.33:60434/10.128.0.12:51820
  Relay server address: rels://streamline-es-mad1-0.relay.netbird.io:443
  Last connection update: 1 hour, 37 minutes ago
  Last WireGuard handshake: 1 minute, 5 seconds ago
  Transfer status (received/sent) 6.5 KiB/10.3 KiB
  Quantum resistance: false
  Networks: -
  Latency: 85.6ms

Understanding the output:

Common Scenarios

Both candidates are host:

ICE candidate (Local/Remote): host/host

Both peers can see each other's direct IP addresses - they're on the same network or have public IPs.

One is srflx (server reflexive):

ICE candidate (Local/Remote): host/srflx

One peer has a direct IP, the other is behind NAT. The NAT was successfully traversed.

Both are srflx:

ICE candidate (Local/Remote): srflx/srflx

Both peers are behind NAT, but hole punching succeeded.

One or both are relay:

ICE candidate (Local/Remote): relay/host

P2P failed for at least one direction; traffic flows through relay.

How NetBird Establishes Connections

NetBird uses the ICE (Interactive Connectivity Establishment) protocol to find the best possible connection path between two peers. ICE is the same technology that powers WebRTC video calls.

The Connection Process

When two NetBird peers need to connect:

1. Candidate Gathering

Each peer discovers all possible ways it can be reached:

• Host candidates: Local IP addresses on the machine (e.g., 192.168.1.50:51820). These are gathered by enumerating all network interfaces on the device.
• Server reflexive candidates: Public IP:port as seen from outside the NAT (e.g., 203.0.113.10:54321). These are discovered by sending a STUN binding request to a STUN server, which responds with the public IP and port it observed.
• Relay candidates: Addresses allocated by TURN/relay servers (fallback option). These are obtained by requesting an allocation from a TURN server, which reserves a port on the relay that can forward traffic to the peer.

2. Candidate Exchange

Peers exchange their discovered candidates through the NetBird Signal service. This exchange is encrypted end-to-end, so the Signal service cannot see the actual candidate information.

3. Connectivity Checks

Both peers simultaneously attempt to reach each other using all candidate pairs. ICE performs these checks in priority order, preferring direct connections over relayed ones:

Priority 1: Host ↔ Host         (direct LAN connection)
Priority 2: Host ↔ Server Reflexive  (direct through NAT)
Priority 3: Server Reflexive ↔ Server Reflexive (both behind NAT)
Priority 4: Relay ↔ Any         (fallback via relay server)

4. Connection Establishment

The first candidate pair that successfully exchanges packets becomes the active connection. NetBird then configures WireGuard to use this path for encrypted tunnel traffic.

NAT Hole Punching

When both peers are behind NAT, NetBird uses a technique called UDP hole punching:

1. Peer A sends a UDP packet to Peer B's public address (this packet may be dropped, but it opens a hole in A's NAT)
2. Peer B simultaneously sends a UDP packet to Peer A's public address (opening a hole in B's NAT)
3. Because both NATs now have outbound mappings, return packets are allowed through
4. The connection is established through both NAT holes

    Peer A                                           Peer B
      │                                                │
      │──────── UDP to B's public addr ───────────────▶│ (may be dropped)
      │                                                │
      │◀─────── UDP to A's public addr ────────────────│ (may be dropped)
      │                                                │
      │         Both NATs now allow return traffic     │
      │                                                │
      │◀───────────── P2P Connection ─────────────────▶│

When hole punching fails:

• Symmetric NAT on either side changes port mappings, breaking the coordination
• Firewalls with strict filtering drop unsolicited UDP
• NAT mappings timeout before the connection is established

Tips for Improving P2P Success

For Home Users

Home networks typically achieve P2P connections without any configuration. If you're having issues:

1. Check your router's NAT type: Some gaming routers have "NAT type" settings (Open, Moderate, Strict). Open is best for P2P.

2. Enable UPnP or NAT-PMP: These protocols allow applications to request port mappings automatically.

3. Avoid double NAT: If your ISP provides a router and you have your own, you may have two layers of NAT. Consider putting the ISP router in bridge mode.

For Corporate Networks

Corporate environments are often more restrictive. Work with your IT team to:

1. Allow UDP outbound: NetBird works best when UDP traffic is permitted to the STUN/TURN servers.

2. Whitelist NetBird endpoints: See the FAQ for the list of endpoints and ports.

3. Consider split tunneling: If full P2P isn't possible, ensure the relay ports are accessible.

For Mobile Users

Mobile connections are inherently variable. To improve reliability:

1. Wi-Fi vs. Cellular: Wi-Fi typically has better NAT traversal than cellular CGNAT.

2. Stable connections: Moving between cell towers causes IP changes and reconnections.

3. Expect some relayed connections: CGNAT makes P2P harder; relayed connections are normal.

NetBird's Relay Infrastructure

NetBird provides globally distributed relay servers to ensure minimal performance impact and connectivity even in the most restrictive networks. The relay system supports two transport protocols:

• QUIC: High-performance UDP-based transport (primary)
• WebSocket: TCP-based transport that works over port 443 (fallback when UDP is blocked)

The WebSocket transport is particularly important for corporate networks that only allow HTTPS traffic, as it appears as standard web traffic to firewalls.

For legacy compatibility, NetBird also supports TURN (Coturn) servers, though the native relay is recommended for new deployments.

Summary

NetBird is designed to work in all these environments. When P2P isn't possible, the relay fallback ensures you stay connected. The connection type affects latency and throughput, but security remains the same - your traffic is always encrypted end-to-end with WireGuard.