videocalling
Back to Glossary

NAT (Network Address Translation)

Technical

Technology allowing multiple devices to share a single public IP address

What is NAT?

Network Address Translation (NAT) is a networking technology that allows multiple devices on a private network to share a single public IP address when accessing the internet. Think of NAT as the receptionist at a large office building—external visitors only see one address (the building's address), while internally there are hundreds of individual offices with their own internal numbers.

Your home router uses NAT to give your laptop, phone, smart TV, and other devices internet access through one public IP address provided by your ISP. Each device gets a private IP address (like 192.168.1.100, 192.168.1.101, etc.) that only works on your local network. When these devices communicate with the internet, the router translates their private addresses to its public address, keeping track of which connection belongs to which device.

While NAT solves critical problems with IPv4 address exhaustion, it creates significant challenges for peer-to-peer applications like WebRTC video calling. Understanding NAT is essential to understanding why STUN and TURN servers exist.

Why NAT Exists

The internet was designed with IPv4 addresses—32-bit numbers that allow for about 4.3 billion unique addresses. In the 1980s, this seemed inexhaustible. But with smartphones, IoT devices, and multiple internet-connected devices per household, we've long since run out of IPv4 addresses.

NAT emerged as a practical solution: instead of giving every device a public IP address, give each household or organization one public IP, and let a router manage private IP addresses internally. This延迟 IPv4 exhaustion for decades and remains the dominant approach even as IPv6 slowly rolls out (IPv6 would eliminate the need for NAT, but adoption remains below 40% globally as of 2025).

NAT also provides a security benefit: devices behind NAT are not directly reachable from the internet by default, creating a natural firewall that blocks unsolicited incoming connections.

How NAT Works: The Translation Process

Outbound Connections

When your laptop (private IP 192.168.1.100) makes a request to a website:

  1. Your laptop sends a packet with source address 192.168.1.100:54321 (private IP and random port) and destination 93.184.216.34:443 (the website's public IP and HTTPS port)
  2. The router receives this packet and replaces the source address with its own public IP and a port it assigns, say 203.0.113.45:60001
  3. The router records this mapping in its NAT table: 192.168.1.100:54321 ↔ 203.0.113.45:60001
  4. The packet reaches the website's server, which sees the source as 203.0.113.45:60001 and has no idea it's actually coming from a private network

Inbound Responses

When the website responds:

  1. The response packet has destination 203.0.113.45:60001
  2. The router looks up port 60001 in its NAT table and finds it maps to 192.168.1.100:54321
  3. The router replaces the destination address with the private IP and forwards the packet to your laptop
  4. Your laptop receives the response and everything works seamlessly

This works perfectly for client-server communications where you initiate connections. But it breaks peer-to-peer connections.

The Peer-to-Peer Problem

Imagine you want to start a WebRTC video call with a friend. Both of you are behind NAT routers. You can't tell your friend to connect to 192.168.1.100 because that's a private address—it doesn't exist on the public internet, and even if it did, millions of networks use the same private IP ranges.

Even if you share your router's public IP, there's another problem: your router's NAT table only has mappings for connections YOU initiated. If your friend tries to send you a packet at your router's public IP, the router doesn't know which internal device should receive it and drops the packet.

This is the fundamental NAT problem for WebRTC: both peers are reachable only through their routers' public IPs, but neither router knows how to route incoming peer-to-peer connection attempts to the correct internal device.

Types of NAT

Not all NAT implementations are equal. Different NAT types have drastically different impacts on WebRTC connection success rates. The crucial distinction is between Cone NAT (permissive) and Symmetric NAT (restrictive).

Full Cone NAT

The most permissive type. Once the router creates a mapping from an internal IP:port to an external IP:port, ANY external host can send packets to that external address, and they'll be forwarded to the internal device.

Example: Your laptop 192.168.1.100:54321 sends a packet to anywhere, and the router maps it to 203.0.113.45:60001. Now ANY internet host can send packets to 203.0.113.45:60001 and reach your laptop.

WebRTC impact: STUN works perfectly. You can discover your public address and share it with peers who can then connect directly. Success rate: ~95%.

Restricted Cone NAT

Slightly more restrictive. The router creates the same consistent mapping, but only accepts incoming packets from IP addresses the internal device has previously contacted.

Example: Your laptop sends to 93.184.216.34, creating mapping 192.168.1.100:54321 ↔ 203.0.113.45:60001. Now only 93.184.216.34 can send packets back to port 60001. Any other IP trying to reach 60001 is blocked.

WebRTC impact: STUN still works with ICE's simultaneous connection attempts. Both peers send packets to each other at the same time, creating the necessary mappings. Success rate: ~85%.

Port-Restricted Cone NAT

Even more restrictive. Like Restricted Cone, but also checks the source port. The router only accepts incoming packets from the exact IP:port combination the internal device contacted.

Example: Your laptop sends to 93.184.216.34:443. Only packets from exactly 93.184.216.34:443 can reach your laptop through the NAT mapping. Packets from 93.184.216.34:8080 (same IP, different port) are blocked.

WebRTC impact: STUN can still work with proper ICE negotiation, but success depends on both peers' NAT types. Success rate: ~75-80%. Most consumer routers in 2025 behave as Port-Restricted Cone NAT.

Symmetric NAT

The most restrictive and problematic type for WebRTC. Symmetric NAT creates different port mappings for each destination. When you send packets to different external addresses, the router assigns a different external port for each connection.

Example: Your laptop 192.168.1.100:54321 sends to a STUN server at 64.233.160.127:19302, and the router maps this to 203.0.113.45:60001. Great! But when your laptop sends to a peer at 198.51.100.50:55555, the router creates a completely different mapping: 203.0.113.45:60002 (different external port).

The problem: STUN discovers 203.0.113.45:60001, but that address only works for talking back to the STUN server. When you share this address with a peer and they try to connect, you're actually sending to them from a different port (60002), so the connection fails.

WebRTC impact: STUN is useless. The only solution is TURN relay. Success rate without TURN: ~0%. With TURN: 100%.

NAT in the Real World

Consumer Routers

Most home and small business routers implement Port-Restricted Cone NAT. This provides a good balance between security and connectivity. Brands like Linksys, Netgear, TP-Link, and ASUS typically use this approach, which is why 75-85% of WebRTC connections succeed with STUN alone.

Carrier-Grade NAT (CGNAT)

Mobile networks and some ISPs use CGNAT—NAT implemented at the ISP level to share public IPs across hundreds or thousands of customers. CGNAT is almost always Symmetric NAT, which is why mobile WebRTC calls often require TURN relays.

If you're on mobile data and notice your video calls routing through servers rather than connecting directly, CGNAT is likely the reason.

Corporate Networks

Enterprise networks often combine Symmetric NAT with strict firewalls, making direct peer-to-peer connections nearly impossible. This is why WebRTC applications targeted at business users must provision sufficient TURN relay capacity—expect 40-50% of corporate users to require TURN, versus 15-25% for general consumer usage.

Double NAT

Some users experience double NAT: their router behind their ISP's router, or a personal router behind a building's router. This compounds the problem—packets must traverse two layers of NAT, each with its own mapping table. While STUN can sometimes still work, success rates drop significantly, and TURN becomes more critical.

How WebRTC Solves NAT: The Three-Pronged Approach

1. STUN (Discovery)

STUN servers help you discover your public IP and port as seen from the internet. By querying a STUN server, you learn your router's external address, which works for Cone NAT types. STUN is lightweight and free to operate, which is why public STUN servers exist.

2. ICE (Intelligent Selection)

ICE framework tries multiple connection strategies simultaneously: direct LAN connections, STUN-discovered public addresses, and TURN relay addresses. It tests all possibilities and selects the best working path. This systematic approach maximizes connection success rates.

3. TURN (Last Resort)

When STUN fails (Symmetric NAT, restrictive firewalls), TURN provides a relay server that both peers can reach. All media flows through the TURN server, which is expensive but guarantees connectivity. TURN is essential for the 15-25% of connections where NAT types prevent direct communication.

Connection Success Rates by NAT Combination

Real-world connection success rates depend on both peers' NAT types:

  • Both Full Cone: ~95% success with STUN
  • Both Restricted Cone: ~90% success with STUN + ICE
  • Both Port-Restricted Cone: ~80-85% success with STUN + ICE
  • One Symmetric, one Cone: ~30-40% success (depends on cone type), TURN recommended
  • Both Symmetric: ~0% success without TURN, 100% with TURN

Chrome's telemetry data shows that across all internet traffic, direct connections (host + server-reflexive candidates) succeed in roughly 75-80% of sessions, with the remaining 20-25% requiring TURN relay. This aligns with the prevalence of Port-Restricted Cone NAT in consumer networks and Symmetric NAT in mobile/enterprise environments.

NAT and IPv6

IPv6 has 340 undecillion addresses (340 trillion trillion trillion)—enough to give every device on Earth multiple unique public addresses. In theory, IPv6 eliminates the need for NAT entirely, removing the peer-to-peer connection problem.

However, IPv6 adoption remains slow. As of 2025, Google reports roughly 40-45% of traffic arrives via IPv6, meaning the majority still uses IPv4 + NAT. Even in IPv6-enabled networks, routers often implement firewall rules that mimic NAT behavior for security, so the connectivity challenges don't completely disappear.

For WebRTC developers, planning for NAT traversal remains essential for the foreseeable future. STUN and TURN infrastructure will be necessary for years to come.

Debugging NAT Issues

When WebRTC connections fail, NAT is often the culprit. Check for these indicators:

  • ICE gathering completes but all connection attempts timeout → Likely Symmetric NAT on both sides without TURN
  • Server reflexive candidates gathered but connection fails → Firewall blocking STUN-discovered ports
  • Only relay candidates work → One or both peers behind Symmetric NAT
  • Connection works on WiFi but fails on mobile data → Mobile carrier using CGNAT (Symmetric NAT)

Tools like WebRTC troubleshooter or examining chrome://webrtc-internals can show which candidate types succeeded, helping identify NAT-related issues.

The Bottom Line

NAT is a necessary evil of modern internet architecture. It solved IPv4 address exhaustion but created the peer-to-peer connectivity problem that WebRTC must overcome. Understanding NAT types—and particularly recognizing that Symmetric NAT defeats STUN—is essential for planning WebRTC infrastructure.

The combination of NAT diversity across networks (consumer routers, CGNAT, corporate firewalls) means you cannot rely solely on STUN. TURN relay infrastructure is mandatory for production WebRTC applications, even though only 15-25% of connections will need it. The alternative—accepting that a quarter of your users simply cannot connect—is unacceptable for any serious application.

NAT isn't going away soon. IPv6 adoption is gradual, and even in pure IPv6 environments, firewall-like restrictions often remain for security. For WebRTC developers in 2025 and beyond, mastering NAT traversal through STUN, TURN, and ICE is non-negotiable.

References

Related Terms

STUN (Session Traversal Utilities for NAT)TURN (Traversal Using Relays around NAT)ICE (Interactive Connectivity Establishment)
Back to Glossary