Networking · 18.03.2025

NAT Traversal - Why P2P Connections Are A Nightmare

The Problem That Broke My P2P Dreams

I'll never forget the first time I tried to build a peer-to-peer file sharing app. The concept seemed simple: two computers, direct connection, transfer files. No server needed. Pure P2P elegance.

I got it working perfectly on my local network. My laptop could talk to my desktop, files flew across at gigabit speeds. I was feeling like a networking wizard. Then I tried it across the internet.

Nothing. Absolutely nothing. The connection just... timed out. I checked my code a hundred times. I verified the IP addresses. I made sure the firewall was off. Still nothing. Then I tried it with a friend across town. Same story. Connection timeout.

What I didn't understand then - what most people don't understand - is that the internet is broken for peer-to-peer connections. Or more accurately, NAT broke it, and we've been dealing with the consequences ever since.

It took me three weeks to figure this out. I implemented STUN. I cursed at symmetric NAT. I finally got it working... sometimes. And that "sometimes" is the real story here.

This post is about why your home router is lying to you, why there are four different types of NAT (each progressively more difficult), how UDP hole punching works, and why services like Zoom need thousands of TURN servers just to make video calls work.

The Internet Before NAT: The Good Old Days

Let's rewind to understand how we got here. In the early days of the internet (1980s-1990s), every computer had a public IP address. This was glorious for networking:

The Simple Internet (Pre-NAT):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Alice's Computer Bob's Computer
IP: 12.34.56.78 IP: 98.76.54.32
Port: 5000 Port: 5000
 │ │
 │ "Hey Bob, this is Alice at │
 │ 12.34.56.78:5000" │
 ├──────────────────────────────────>
 │ │
 │ "Hey Alice, got your message!" │
 <──────────────────────────────────┤
 │ │

Connection established!
Both can directly reach each other.
No magic needed.

If you wanted to connect to someone, you just needed their IP address and port number. Done. P2P was trivial.

Then We Ran Out Of IP Addresses

The problem? IPv4 only has about 4.3 billion addresses (2^32). That sounds like a lot until you realize there are now tens of billions of devices wanting internet access. Smartphones, tablets, laptops, IoT devices, smart fridges... we ran out of addresses fast.

The long-term solution was IPv6, which has 340 undecillion addresses (that's 340 with 36 zeros after it - basically infinite). But IPv6 deployment has been... slow. Like, "we've been rolling it out for 25 years and it's still not universal" slow.

The short-term hack? Network Address Translation (NAT).

NAT: The Hack That Broke P2P

NAT is a clever trick that lets multiple devices share a single public IP address. Your home router does this. Your office network does this. Your coffee shop WiFi does this.

Here's how it works:

NAT In Action:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Your Home Network:
┌─────────────────────────────────────────┐
│ Router (NAT Device) │
│ Public IP: 203.0.113.50 │
│ │
│ Private Network: 192.168.1.0/24 │
│ ┌───────────┐ ┌───────────┐ │
│ │ Laptop │ │ Phone │ │
│ │192.168.1.2│ │192.168.1.3│ │
│ └───────────┘ └───────────┘ │
└─────────────────────────────────────────┘
 │
 │ All devices share ONE public IP
 ▼
 The Internet
 
From outside, everyone sees: 203.0.113.50
But inside, you have a private network!

The NAT Translation Table

Here's the key: when you make an outgoing connection, your router creates a mapping:

NAT Mapping Table:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Internal Address External Address Remote Server
──────────────── ──────────────── ─────────────
192.168.1.2:50000 → 203.0.113.50:45001 → 93.184.216.34:80
192.168.1.2:50001 → 203.0.113.50:45002 → 1.2.3.4:443
192.168.1.3:60000 → 203.0.113.50:45003 → 8.8.8.8:53

When packet arrives at external port 45001,
router knows to forward it to 192.168.1.2:50000

Your laptop at 192.168.1.2:50000 sends a packet to Google. The router:

  1. Replaces your source IP/port with 203.0.113.50:45001
  2. Remembers this mapping
  3. Sends packet to Google
  4. When Google replies to 203.0.113.50:45001, router looks up mapping
  5. Forwards reply to 192.168.1.2:50000

This is brilliant for client-server connections! You can browse the web, watch YouTube, read email - all works perfectly.

But P2P Is Screwed

Here's the problem: NAT mappings are created by outgoing connections.

If Bob behind his NAT tries to connect to Alice behind her NAT:

The P2P Problem:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Alice's Network: Bob's Network:
┌──────────────────┐ ┌──────────────────┐
│ Router NAT │ │ Router NAT │
│ Public: 1.2.3.4 │ │ Public: 5.6.7.8 │
│ │ │ │
│ Alice: 10.0.0.2 │ │ Bob: 192.168.1.5 │
└──────────────────┘ └──────────────────┘
 │ │
 │ │
 │ Bob tries to connect │
 │ to 1.2.3.4:12345 │
 <──────────────────────────────┤
 │ │
 Alice's router: │
 "Who the hell is this?" │
 "No mapping for port 12345" │
 "DROP PACKET" │

Connection fails. Alice never sees it.
Bob gets a timeout.
P2P is dead.

Alice's router doesn't have a mapping for incoming traffic on port 12345. It doesn't know where to forward it. So it drops it. Game over.

This is why your P2P app that worked perfectly on your local network dies the moment you go across the internet.

The Four Horsemen: Types of NAT

Not all NAT implementations are equal. There are actually four main types, each with different behaviors. And these differences determine whether P2P is possible or impossible.

Type 1: Full Cone NAT (The Good One)

Also called "One-to-One NAT". This is the most permissive type:

Full Cone NAT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Mapping: Internal 10.0.0.2:5000 → External 1.2.3.4:6000

Rule: Once this mapping exists, ANYONE can send
 packets to 1.2.3.4:6000 and they'll be
 forwarded to 10.0.0.2:5000

Example:
1. Alice (10.0.0.2:5000) sends packet to Bob (5.6.7.8:8000)
2. Router creates: 10.0.0.2:5000 ↔ 1.2.3.4:6000
3. Now Bob can reply to 1.2.3.4:6000 
4. But ALSO: Charlie (9.8.7.6:9000) can send to 1.2.3.4:6000 
5. Any source can reach Alice through this mapping!

P2P Friendliness: (Excellent)

Full cone is great for P2P because once you have a mapping, anyone can reach you. But it's rare these days because it's considered a security risk.

Type 2: Restricted Cone NAT (Address-Restricted)

More common. Adds a restriction:

Restricted Cone NAT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Mapping: Internal 10.0.0.2:5000 → External 1.2.3.4:6000

Rule: Only hosts that Alice has SENT TO can send back

Example:
1. Alice (10.0.0.2:5000) sends packet to Bob (5.6.7.8:8000)
2. Router creates: 10.0.0.2:5000 ↔ 1.2.3.4:6000
3. Router also notes: "5.6.7.8 is allowed"
4. Bob (5.6.7.8:8000) can send to 1.2.3.4:6000 
5. Bob (5.6.7.8:9999) can send to 1.2.3.4:6000 (any port from 5.6.7.8)
6. Charlie (9.8.7.6:9000) sends to 1.2.3.4:6000 (blocked! Alice never sent to 9.8.7.6)

P2P Friendliness: (Good, with hole punching)

This is more secure (you can only receive from addresses you've contacted) but still P2P-friendly. The trick is that any port from the allowed address works.

Type 3: Port-Restricted Cone NAT

Even more restrictive:

Port-Restricted Cone NAT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Mapping: Internal 10.0.0.2:5000 → External 1.2.3.4:6000

Rule: Only the exact IP:PORT combo that Alice sent to can reply

Example:
1. Alice (10.0.0.2:5000) sends packet to Bob (5.6.7.8:8000)
2. Router creates: 10.0.0.2:5000 ↔ 1.2.3.4:6000
3. Router notes: "5.6.7.8:8000 is allowed"
4. Bob (5.6.7.8:8000) can send to 1.2.3.4:6000 
5. Bob (5.6.7.8:9999) sends to 1.2.3.4:6000 (wrong port! blocked)
6. Charlie (9.8.7.6:9000) sends to 1.2.3.4:6000 (blocked)

P2P Friendliness: (Okay, hole punching harder)

Most home routers are this type. P2P is still possible but requires more coordination.

Type 4: Symmetric NAT (The Evil One)

This is the nightmare scenario:

Symmetric NAT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Rule: A DIFFERENT external port is used for EACH destination

Example:
1. Alice (10.0.0.2:5000) sends to Bob (5.6.7.8:8000)
 Router creates: 10.0.0.2:5000 → 1.2.3.4:6001 for dest 5.6.7.8:8000
 
2. Alice (10.0.0.2:5000) sends to Charlie (9.8.7.6:9000)
 Router creates: 10.0.0.2:5000 → 1.2.3.4:6002 for dest 9.8.7.6:9000
 
3. Same internal socket, DIFFERENT external ports!

4. Bob knows Alice is at 1.2.3.4:6001
5. Charlie knows Alice is at 1.2.3.4:6002
6. If Bob tries to connect to 1.2.3.4:6002, BLOCKED!
 (That mapping is only for traffic to Charlie)

P2P Friendliness: (Terrible, usually impossible)

Symmetric NAT destroys most P2P techniques because you can't predict what external port will be used for a new connection. Corporate networks and mobile carriers often use symmetric NAT.

UDP Hole Punching: The Clever Hack

So how do P2P apps work at all? Enter UDP hole punching - a beautiful hack that exploits NAT behavior.

The key insight: if both sides send packets at the same time, they can create the mappings needed for each other.

The Hole Punching Dance

You need a third party: a rendezvous server with a public IP. Here's the full sequence:

UDP Hole Punching:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Rendezvous Server (public): 200.1.2.3:3478

Step 1: Both clients register with server
────────────────────────────────────────────

Alice's Network: Server: Bob's Network:
┌──────────────┐ ┌────┐ ┌──────────────┐
│NAT 1.2.3.4 │ │ │ │NAT 5.6.7.8 │
│ Alice │ │ │ │ Bob │
│ 10.0.0.2:5000│ │ │ │ 192.168.1.5: │
└──────────────┘ └────┘ │ 6000 │
 │ │ └──────────────┘
 │ Register │ │
 ├────────────────────────►│ │
 │ │◄─────────────────────┤
 │ │ Register │
 │ │ │

Server now knows:
- Alice is at 1.2.3.4:50001 (external)
- Bob is at 5.6.7.8:60001 (external)


Step 2: Server tells each about the other
──────────────────────────────────────────

 │ │ │
 │◄────────────────────────┤ │
 │ "Bob is at 5.6.7.8:60001" │
 │ ├─────────────────────►│
 │ │"Alice is at 1.2.3.4: │
 │ │ 50001" │
 │ │ │


Step 3: SIMULTANEOUS hole punching
───────────────────────────────────

 │ │
 │ Send to 5.6.7.8:60001 │
 ├────────────────────────X (blocked by Bob's NAT)
 │ │
 │ But! This creates mapping at Alice's NAT: │
 │ 10.0.0.2:5000 ↔ 1.2.3.4:50001 │
 │ for destination 5.6.7.8:60001 │
 │ │
 │ X◄───────────────────────┤
 │ (blocked by Alice's NAT) │
 │ Send to 1.2.3.4:50001 │
 │ │
 │ But! This creates mapping at Bob's NAT: │
 │ 192.168.1.5:6000 ↔ 5.6.7.8:60001 │
 │ for destination 1.2.3.4:50001 │
 │ │


Step 4: Try again - now it works!
──────────────────────────────────

 │ │
 │ Send to 5.6.7.8:60001 │
 ├───────────────────────────────────────────────►│
 │ Success!
 │ │
 │ │
 │◄───────────────────────────────────────────────┤
 │ Success! Send to 1.2.3.4:50001 │
 │ │

Direct P2P connection established!
The "holes" are punched!

Why This Works

The magic is in the timing:

  1. Alice sends to Bob: Alice's NAT creates a mapping for destination 5.6.7.8:60001. Even though Bob's NAT blocks this first packet, Alice's NAT is now ready to receive from 5.6.7.8:60001.

  2. Bob sends to Alice: Bob's NAT creates a mapping for destination 1.2.3.4:50001. Even though Alice's NAT blocks this first packet, Bob's NAT is now ready to receive from 1.2.3.4:50001.

  3. The holes are punched: Both NATs now have the necessary mappings. Subsequent packets from both sides succeed!

This works with Restricted Cone and Port-Restricted Cone NAT. It's beautiful. It's a hack. And it fails with Symmetric NAT.

The Symmetric NAT Problem

With symmetric NAT, this breaks down:

Why Hole Punching Fails With Symmetric NAT:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Alice (behind Symmetric NAT):

1. Alice sends to Server (200.1.2.3:3478)
 Mapping created: Internal 10.0.0.2:5000 → External 1.2.3.4:50001
 
2. Server tells Bob: "Alice is at 1.2.3.4:50001"

3. Alice tries to send to Bob (5.6.7.8:60001)
 NEW mapping created: Internal 10.0.0.2:5000 → External 1.2.3.4:50002
 (Different destination = different external port!)
 
4. Bob tries to send to 1.2.3.4:50001 (what server told him)
 But Alice's hole punch came from 1.2.3.4:50002!
 Alice's NAT blocks it (no mapping for 50001 from Bob)
 
5. Alice tries to send to 5.6.7.8:60001
 But Bob is expecting packets from 1.2.3.4:50001, not 50002!
 If Bob has symmetric NAT too, his external port also changed!
 
Result: Both sides are sending to the wrong ports.
Connection fails. P2P impossible.

This is why some people can video chat no problem, while others always have issues. It's NAT type lottery.

STUN: Session Traversal Utilities for NAT

STUN is a protocol that helps you discover:

  1. Your public IP and port (as seen by the internet)
  2. What type of NAT you're behind
  3. Whether P2P is likely to work

How STUN Works

A STUN server is just a simple server on the internet that echoes back your address:

STUN Protocol:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Client (behind NAT): STUN Server (public):
10.0.0.2:5000 200.1.2.3:3478
 │ │
 │ STUN Binding Request │
 ├──────────────────────────►│
 │ │
 │ (NAT translates to) │
 │ 1.2.3.4:50001 → Server │
 │ │
 │ STUN Binding Response │
 │ "Your address is │
 │ 1.2.3.4:50001" │
 │◄──────────────────────────┤
 │ │

Client now knows its public endpoint!

STUN servers are cheap to run (they just echo back addresses) and there are many public ones:

  • Google: stun.l.google.com:19302
  • Twilio: stun.twilio.com:3478
  • OpenSTUN: stun.stunprotocol.org:3478

STUN NAT Type Detection

STUN can detect NAT type with multiple tests:

STUN NAT Detection Algorithm:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Test 1: Send to Server IP1:Port1
 Get back: External address A

Test 2: Send to Server IP2:Port2 (different server)
 Get back: External address B

If A == B:
 → Cone NAT (could be Full, Restricted, or Port-Restricted)
 
 Test 3: Server sends from different IP to your A
 Does it arrive?
 
 If YES:
 → Full Cone NAT (yay!)
 If NO:
 Test 4: Server sends from same IP, different port
 Does it arrive?
 
 If YES:
 → Restricted Cone NAT
 If NO:
 → Port-Restricted Cone NAT
 
If A ≠ B:
 → Symmetric NAT (oh no...)
 P2P will be very difficult

STUN Limitations

STUN is great, but has limits:

  1. Symmetric NAT: STUN can detect it, but can't fix it
  2. Firewall blocking: Some firewalls block UDP entirely
  3. Port prediction: Some symmetric NATs use predictable ports (you can try to guess), but it's unreliable
  4. IPv6 transition: STUN was designed for IPv4; IPv6 has different issues

TURN: Traversal Using Relays around NAT

When hole punching fails (symmetric NAT on both sides, or blocked UDP), you need plan B: TURN servers.

TURN is the nuclear option: instead of P2P, you relay everything through a server.

TURN Relay:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Alice's Network: TURN Server: Bob's Network:
┌──────────────┐ ┌─────────────┐ ┌──────────────┐
│ Alice │ │Public Server│ │ Bob │
│ │ │ │ │ │
│ │ │ │ │ │
└──────────────┘ └─────────────┘ └──────────────┘
 │ │ │
 │ Allocate relay │ │
 ├────────────────────────►│ │
 │ │◄─────────────────────┤
 │ │ Allocate relay │
 │ │ │
 │ Send data │ │
 ├────────────────────────►│ │
 │ ├─────────────────────►│
 │ │ Forward data │
 │ │ │
 │ │◄─────────────────────┤
 │ │ Send data │
 │◄────────────────────────┤ │
 │ Forward data │ │
 │ │ │

Not P2P at all! Pure relay.
All traffic goes through server.

The TURN Problem: Cost

TURN servers are expensive to operate:

  1. Bandwidth: All your data flows through them. Video call? That's gigabytes per hour.
  2. Resources: Need beefy servers with good network connectivity
  3. Scale: Big services need thousands of TURN servers worldwide

This is why:

  • Zoom has data centers everywhere (for TURN relaying)
  • Discord spent years optimizing voice routing
  • WebRTC apps prefer direct P2P but fall back to TURN
  • Corporate VPNs exist (controlled routing, no need for TURN)

TURN Allocation

TURN isn't just "forward everything". It's more sophisticated:

TURN Allocation Process:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Client requests allocation:
 "I need a relay address for peer connections"
 
2. TURN server allocates:
 - A relay transport address (IP:Port on server)
 - Unique permissions for this allocation
 
3. Client can create "channels":
 - Channel to peer 1 (Bob)
 - Channel to peer 2 (Charlie)
 - Each channel has an ID
 
4. When sending data:
 - Client sends to TURN with channel ID
 - TURN forwards to correct peer
 - Efficient (no need to include peer address every time)

5. Permissions and lifetime:
 - Allocations expire (typically 10 minutes)
 - Must be refreshed with keep-alives
 - Can be terminated when connection ends

ICE: Interactive Connectivity Establishment

ICE is the protocol that puts it all together. It's the strategy for trying everything:

ICE Connection Strategy:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 1: Gather all possible addresses (candidates)
───────────────────────────────────────────────────

Host candidates:
 - Your local IP (10.0.0.2:5000)
 
Server Reflexive candidates (from STUN):
 - Your public IP (1.2.3.4:50001)
 
Relayed candidates (from TURN):
 - TURN server relay (200.1.2.3:12345)


Step 2: Exchange candidates with peer
──────────────────────────────────────

Alice tells Bob all her addresses:
 - 10.0.0.2:5000 (host)
 - 1.2.3.4:50001 (server reflexive)
 - 200.1.2.3:12345 (relay)
 
Bob tells Alice all his addresses:
 - 192.168.1.5:6000 (host)
 - 5.6.7.8:60001 (server reflexive)
 - 201.2.3.4:54321 (relay)


Step 3: Try them in priority order
───────────────────────────────────

Priority (best to worst):
1. Host-to-Host (direct local)
2. Host-to-Server Reflexive (local to public)
3. Server Reflexive-to-Server Reflexive (P2P through NAT)
4. Server Reflexive-to-Relay (one side relayed)
5. Relay-to-Relay (both sides relayed - worst case)

Alice tries:
 10.0.0.2:5000 → 192.168.1.5:6000 (fails, different networks)
 10.0.0.2:5000 → 5.6.7.8:60001 (fails, NAT blocks)
 1.2.3.4:50001 → 5.6.7.8:60001 (success! hole punching worked!)
 
Connection established!
Use server reflexive pair (P2P through NAT).


If all direct attempts fail:
────────────────────────────

Alice tries:
 1.2.3.4:50001 → 5.6.7.8:60001 (fails, symmetric NAT)
 1.2.3.4:50001 → 201.2.3.4:54321 (success! Bob's relay)
 
Connection established through TURN relay.
Not ideal, but works.

ICE Connectivity Checks

ICE does more than just try addresses. It performs connectivity checks with STUN binding requests:

ICE Connectivity Check:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

For each candidate pair (Alice addr → Bob addr):

1. Send STUN Binding Request from Alice to Bob
2. If Bob receives it, send STUN Binding Response back
3. Mark this pair as "working"
4. Calculate round-trip time (for quality metrics)

Multiple pairs might work!
Choose best based on:
- Type (prefer direct over relay)
- RTT (prefer low latency)
- Connection quality

Example results:
 Pair 1: Host-to-Host (FAILED)
 Pair 2: ServerReflexive-to-ServerReflexive (SUCCESS, 50ms RTT)
 Pair 3: Relay-to-Relay (SUCCESS, 150ms RTT)
 
Choose Pair 2 (better latency, not relayed)

This is what happens when you start a video call:

  1. WebRTC gathers candidates (a few hundred milliseconds)
  2. Exchanges candidates with peer (via signaling server)
  3. Performs connectivity checks (another few hundred ms)
  4. Chooses best working pair
  5. Media starts flowing

That initial delay? That's ICE doing its magic.

Port Forwarding and UPnP: Manual vs Automatic

There are two other ways to deal with NAT: configure it manually, or have devices configure it automatically.

Port Forwarding (Manual)

You can manually tell your router "forward port X to internal device Y":

Manual Port Forwarding:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Router configuration:
 External Port 25565 → Internal 192.168.1.100:25565
 
Now anyone on internet can reach:
 YourPublicIP:25565 → Your Minecraft server
 
Benefits:
 Reliable (permanent mapping)
 Predictable (always same port)
 No protocols needed
 
Drawbacks:
 Manual setup required
 Most users don't know how
 One port per device
 Security risk (open port)

This is why gaming servers, Minecraft, BitTorrent, etc. often ask you to "forward a port". It bypasses NAT traversal entirely.

UPnP/NAT-PMP (Automatic)

UPnP (Universal Plug and Play) and NAT-PMP (NAT Port Mapping Protocol) let programs automatically create port forwards:

UPnP Port Mapping:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Your Game:
 │
 │ "Hey router, I need external port 5000
 │ forwarded to my internal 192.168.1.5:5000"
 │
 ├─────────► Router (via UPnP)
 │
 │ "Sure! Mapping created:
 │ External 5000 → 192.168.1.5:5000
 │ Lease time: 1 hour"
 │◄─────────┤
 │
 
Router automatically creates mapping!
Game can tell friends: "Connect to MyPublicIP:5000"

Benefits:
 No user configuration
 Works automatically
 Temporary (expires)
 
Drawbacks:
 Not all routers support it
 Often disabled by default (security)
 Can be abused by malware

This is how Xbox Live, PlayStation Network, Steam, etc. can work "out of the box" - they use UPnP to configure your router automatically.

But many security-conscious people disable UPnP because:

  1. Malware can use it to open ports
  2. Some UPnP implementations had vulnerabilities
  3. It reduces control over your network

Real-World Examples: Why Things Fail

Let's look at actual scenarios and why they fail or succeed:

Scenario 1: Video Call Success

Alice and Bob video calling:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Alice:
- Behind Port-Restricted Cone NAT (common home router)
- Good internet: 100 Mbps

Bob:
- Behind Restricted Cone NAT (also home router)
- Good internet: 50 Mbps

Connection process:
1. Both connect to signaling server (WebRTC)
2. ICE gathers candidates
3. STUN reveals public addresses
4. Hole punching succeeds
5. Direct P2P connection established!

Result:
 Video quality: Excellent (direct P2P, low latency)
 Cost: Minimal (just signaling server)
 Bandwidth: Only between Alice and Bob

Scenario 2: Video Call Struggles

Alice calling Charlie:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Alice:
- Behind Port-Restricted Cone NAT (home)
- Good internet: 100 Mbps

Charlie:
- Behind Symmetric NAT (corporate network)
- Filtered network (IT department blocks lots of stuff)
- Mediocre internet: 10 Mbps

Connection process:
1. Both connect to signaling server
2. ICE gathers candidates
3. STUN works for Alice, detects Symmetric NAT for Charlie
4. Hole punching fails (Symmetric NAT)
5. Fallback to TURN relay

Result:
 Video quality: Degraded (relayed through TURN server)
 Latency: Higher (extra hop through relay)
 Cost: Expensive (all data through company's TURN servers)
 Bandwidth: Limited by relay server capacity

Scenario 3: Multiplayer Game Failure

Gaming lobby with 8 players:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Setup:
- 5 players: Cone NAT (various types)
- 2 players: Symmetric NAT
- 1 player: Strict firewall (blocks most UDP)

Problem:
- P2P mesh required (all-to-all connections)
- That's 8×7/2 = 28 connections needed
- With 2 symmetric NATs and 1 firewall...

Results:
 Cone NAT players: Can connect to each other (23 connections)
 Symmetric NAT players: Can't connect to each other (2 fail)
 Firewall player: Can't connect to anyone (7 fail)
 
Total: 9 failed connections out of 28

Game is unplayable.
Host migrates to dedicated server model.

This is why:

  • Dedicated servers are still common in competitive games
  • Peer-to-peer games limit player counts
  • Hybrid models use dedicated servers for problematic clients

Scenario 4: BitTorrent Success (Sort Of)

BitTorrent swarm:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

You: Behind Port-Restricted Cone NAT
Swarm: 500 peers, mixed NAT types

Problem:
- You can initiate connections (outgoing = create mapping)
- But can't receive connections (no mapping exists)

Solution:
1. Connect to tracker
2. Get list of peers
3. Initiate connections to peers (you become "leecher")
4. Those connections work (you created the mappings)
5. Can't act as "seeder" for incoming requests

Result:
 Can download (initiate connections)
 Limited upload (only to peers you connected to first)
 Can't help the swarm as much
 
Fix: Port forwarding or UPnP
Now you can receive incoming connections!
Upload ratio improves.

This is why BitTorrent clients pester you to forward a port - it dramatically improves swarm health.

Why Some Things Just Work™

You might wonder: "But video calls usually work! WhatsApp, Zoom, Teams - they just work!"

They work because companies throw massive resources at the problem:

Example: Zoom's Infrastructure

Zoom's NAT Traversal Strategy:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. Try P2P first (ICE + STUN):
 - If successful: Great! Low latency, low cost
 - Success rate: ~30-40% (depends on NAT types)

2. If P2P fails, use relay:
 - Zoom has 1000+ TURN servers worldwide
 - Geographically distributed (low latency)
 - Massive bandwidth capacity
 
3. Optimize routing:
 - Choose relay closest to both parties
 - Load balance across servers
 - Monitor quality, reroute if needed
 
4. Adaptive quality:
 - If relay is congested, reduce video quality
 - Prefer audio over video in bad conditions
 - Grace degradation

Cost:
- Infrastructure: $$$$$
- Bandwidth: $$$$
- R&D: $$$

Zoom spends millions on infrastructure so that "it just works" for you.

Why Your P2P App Can't Compete

When you build a hobby P2P app:

  • No budget for global TURN servers
  • Can't afford massive bandwidth
  • Can't handle asymmetric NAT cases
  • No adaptive quality algorithms
  • No 24/7 monitoring and optimization

Result: Your app works great in lab conditions, fails in real world.

This is the harsh reality of P2P in a NAT-ed world.

The IPv6 Hope (Spoiler: It's Complicated)

IPv6 was supposed to fix this. Every device gets a public address. No more NAT. P2P should just work!

Except:

IPv6 Reality Check:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Problem 1: Firewall
 - Even without NAT, firewalls exist
 - Incoming connections still blocked by default
 - Need firewall traversal techniques (similar to NAT)
 
Problem 2: Deployment
 - Only ~40% of users have IPv6 (as of 2025)
 - Need IPv4 fallback anyway
 - Dual-stack complexity
 
Problem 3: Mobile Networks
 - Carriers still use NAT64/DNS64
 - Translates IPv6 ↔ IPv4
 - Some of same issues remain
 
Problem 4: Security Mindset
 - Many admins prefer NAT as "security layer"
 - IPv6 adoption resistance
 - "If it ain't broke..."

So even in 2025, NAT traversal is still necessary. IPv6 helps, but doesn't eliminate the problem.

Practical Advice: What Should You Do?

If you're building a P2P app, here's the survival guide:

1. Use WebRTC

Don't reinvent the wheel. WebRTC handles all this:

  • ICE implementation
  • STUN/TURN integration
  • Fallback strategies
  • Cross-platform support
// WebRTC handles the nightmare for you
const pc = new RTCPeerConnection({
 iceServers: [
 { urls: 'stun:stun.l.google.com:19302' },
 { 
 urls: 'turn:your-turn-server.com:3478',
 username: 'user',
 credential: 'pass'
 }
 ]
});
 
// WebRTC does ICE automatically
pc.onicecandidate = (event) => {
 // Send candidate to peer via signaling
};
 
// It just works™ (most of the time)

2. Plan for TURN

Budget for relay servers. You'll need them:

  • 10-30% of connections will need TURN
  • More in corporate environments
  • Essential for symmetric NAT users

Options:

  • Self-hosted: coturn (open source TURN server)
  • Managed services: Twilio, Agora, Vonage
  • Cloud providers: AWS, Azure, GCP all have TURN offerings

3. Test with Real Networks

Don't just test on your local network:

  • Test from home networks (different ISPs)
  • Test from corporate networks (symmetric NAT)
  • Test from mobile networks (cellular data)
  • Test from restrictive countries (China, Iran, etc.)

Use tools:

  • NAT type testing: stunclient utility
  • ICE debugging: Chrome's chrome://webrtc-internals
  • Network simulation: tc command (Linux) to simulate packet loss, latency

4. Have a Dedicated Server Fallback

For critical apps (gaming, video calls), have a dedicated server mode:

  • When P2P fails, fall back to client-server
  • More expensive, but works 100% of time
  • Users prefer "works slow" over "doesn't work"

5. Educate Users

Sometimes manual intervention is needed:

  • Provide clear instructions for port forwarding
  • Detect UPnP and prompt to enable it
  • Show NAT type and explain implications
  • Document firewall requirements

The Future: Better Protocols

The industry is working on improvements:

WebRTC Improvements:

  • Better ICE trickling (faster connection)
  • Improved TURN bandwidth optimization
  • NAT64/IPv6 support

QUIC Protocol:

  • Runs over UDP (like our hole punching)
  • Built-in NAT traversal
  • Better connection migration

WireGuard VPN:

  • Modern VPN protocol
  • Excellent NAT traversal
  • Cryptokey routing (no central servers)

Encrypted SNI (ESNI):

  • Helps with firewall traversal
  • Less middlebox interference

But fundamentally, as long as NAT exists, P2P will be hard.

The Brutal Truth

Here's what nobody tells you when you start building P2P apps:

P2P is broken by default on today's internet. NAT killed it. We've spent 25 years building increasingly complex workarounds - STUN, TURN, ICE, hole punching - just to get back what we had in 1990: computers talking directly to each other.

And even with all these techniques:

  • 10-30% of connections will need relay servers
  • Some NAT combinations are impossible to traverse
  • Corporate networks intentionally block P2P
  • Mobile carriers use symmetric NAT
  • It gets worse every year

This is why:

  • Skype moved from P2P to servers
  • BitTorrent struggles with seeding
  • Gaming uses dedicated servers
  • Video calls need cloud infrastructure
  • WebRTC requires TURN servers

The dream of pure P2P - no servers, just direct connections - is dead for most use cases. We live in a relay-assisted P2P world now.

But understanding this - really understanding NAT types, hole punching, STUN, TURN, and ICE - is what separates people who can build networked apps from people who just copy-paste WebRTC code and hope it works.

Now you know why your P2P connections mysteriously fail. And more importantly, you know what to do about it.

Going Deeper

Want to explore this hands-on?

Test your NAT type:

# Install stun client
sudo apt-get install stun-client # Linux
brew install stuntman-client # macOS
 
# Test your NAT
stunclient stun.l.google.com 19302

Capture STUN traffic:

# Wireshark filter
stun or turn
 
# tcpdump
sudo tcpdump -i any udp port 3478 -w stun.pcap

Run your own TURN server:

# Install coturn
sudo apt-get install coturn
 
# Configure /etc/turnserver.conf
# Run it
turnserver

Test WebRTC:

  • Visit: https://test.webrtc.org/
  • Check: chrome://webrtc-internals during a call
  • See ICE candidates, connection types, statistics

Have fun exploring, and remember: if your P2P connection works, consider it a small miracle.

P.S.: If you want to see a working example of UDP hole punching, or you're curious about more advanced topics like TCP hole punching (yes, it exists and is even more cursed), or you want to understand how Tor/I2P handle NAT traversal, let me know. There's always another layer of complexity to uncover.

← All notes