NAT (Network Address Translation)

Network Address Translation (NAT) is the technology that lets many devices on a private network share a single public IP address on the internet. It runs on almost every home router, office firewall, and mobile carrier gateway in the world.

NAT exists for one reason: there are not enough IPv4 addresses to give every device its own. NAT is the workaround that kept the internet working through the IPv4 shortage, and it’s still the dominant addressing model in 2026 even as IPv6 rolls out.

For WebRTC, NAT is also the single biggest connectivity challenge. Two browsers trying to send media directly to each other don’t know their own public addresses, can’t accept inbound packets without help, and may be behind a NAT type that defeats peer-to-peer altogether. The rest of WebRTC’s connectivity stack – STUN, TURN, ICE – exists primarily to solve NAT.

What does NAT stand for?

NAT stands for Network Address Translation. The “translation” is the rewriting of source and destination IP addresses (and usually port numbers) as packets cross between a private network and the public internet.

How NAT works

A NAT device sits at the boundary between a private LAN – like your home network using 192.168.x.x addresses – and the public internet. When a device on the LAN sends a packet outward, the NAT device:

1. Picks a free port on its public IP address
2. Records a binding in its internal mapping table: (private IP, private port) ↔ (public IP, public port)
3. Rewrites the packet’s source IP and source port to the public values, then forwards it

The server on the public network received that packet and sees as the source address the public IP and port of the NAT device – it is unaware of the private IP and port of the home device. It sends its reply back to the NAT device as this is the source address it sees.

When a reply comes back to the public IP and port of the NAT device, the NAT device looks up the binding, rewrites the destination back to the private values, and delivers the packet to the original device on the LAN.

This binding-based approach is more accurately called Port Address Translation (PAT) or NAT overload, and it’s what almost every consumer NAT actually does.

A few things matter for WebRTC:

• Bindings are created by outbound traffic. No outbound packet, no binding, no way for anything from the outside to reach the device
• Bindings expire. UDP bindings often expire after as little as 30 seconds of idle time. WebRTC sends consent and keepalive packets to prevent this
• Bindings can change. If the device switches networks (Wi-Fi to cellular, or roaming between Wi-Fi access points), the NAT path is gone and a new one has to be established. WebRTC handles this with an ICE restart
• Devices don’t know their public facing IP and port. The assumption is that the connection is always with a server. In P2P topologies, we have two home devices, both behind NAT devices, each inside his own private network. And they need to somehow figure out each other’s public IP address when they themselves are unaware of their own public IP address
• There are different types of NAT devices. Each affects how WebRTC ends up connecting media differently

NAT vs firewall

NAT and firewalls are often the same physical device but they’re conceptually different.

A firewall enforces a security policy – which traffic is allowed, which is blocked. A NAT rewrites addresses so that private devices can use a shared public IP. Most consumer routers do both, which is why people use the words interchangeably (I tend to write Firewall/NAT quite often), but a packet can be NATed without being firewalled (a 1-to-1 NAT in front of a public-facing server) and firewalled without being NATed (a routed firewall in front of public addresses).

For WebRTC, the practical difference is that NAT is almost always recoverable with STUN/TURN/ICE, while a strict corporate firewall blocking UDP outbound is a harder problem and may force you onto TURN/TCP or TURN/TLS as the only option.

NAT types – the four mapping behaviors

Not all NATs behave the same way when external packets try to reach an existing binding. RFC 4787 describes four behaviors, often called “NAT types” (cone vs symmetric):

The key distinction is the bottom row. Symmetric NAT creates a different public mapping for every external destination the device talks to. A device behind symmetric NAT trying to reach 203.0.113.5:443 gets one public port; trying to reach 198.51.100.7:443 gets a different one. From a peer’s perspective, the source address keeps changing, which defeats the address-discovery trick STUN relies on.

Why symmetric NAT breaks P2P

Peer-to-peer (P2P) media in WebRTC works like this:

1. Each peer asks a STUN server “what public address am I using?” and gets back something like 203.0.113.10:62113
2. The peers exchange those addresses through signaling
3. Each peer sends packets to the other’s public address. The first inbound packet creates a return binding on its NAT, and from then on the path is open in both directions

That first request to the STUN server creates a kind of a pinhole which is then used by the other peer to send its media through it. This hack is what fuels most of the WebRTC sessions today.

This works for full-cone, address-restricted, and port-restricted NATs because the public mapping the STUN server saw is the same mapping the peer will use to reach the device.

Behind symmetric NAT, the mapping that the STUN server saw is not the mapping the peer would need to use. When the peer sends a packet to that address, it hits a NAT pinhole that’s only open for the STUN server’s IP, and the packet is dropped.

In practice this means between 10-20% of WebRTC users – depending on geography and carrier – can’t establish a direct P2P connection and have to relay through a TURN server. Mobile networks and some corporate networks are the most common offenders.

The actual percentage varies greatly across geographies and use cases. The more controlled and governed an environment, the higher the chances are that symmetric NAT devices are being deployed and TURN will be needed.

This is why few production WebRTC service runs without TURN. See Do you still need TURN if your media server has a public IP address? for the longer argument.

NAT traversal in WebRTC: STUN, TURN, ICE

The three pieces of the WebRTC NAT-traversal stack:

• STUN – a lightweight protocol that lets a device discover its public IP and port as seen from a server on the internet. Solves “what is my public IP address?”
• TURN – a relay server that forwards media between peers when direct connectivity isn’t possible. Solves the symmetric-NAT and strict-firewall cases
• ICE – the framework that gathers candidate addresses (host, server-reflexive via STUN, relayed via TURN), exchanges them through signaling, and tests them in priority order until one works. In simple terms – uses TURN when STUN isn’t available since we can never really know in advance which to use

ICE tries candidates in this order: host (direct LAN/loopback) → server-reflexive (STUN-discovered public address) → relayed (TURN). The first pair that successfully exchanges connectivity-check packets becomes the active media path. If another path gets connected with a better priority, it will be used instead of the previous one.

Operational NAT issues in WebRTC

Beyond the mapping-type problem, NAT introduces a handful of practical issues every WebRTC implementation has to handle:

• Binding expiry. UDP NAT bindings can expire in as little as 30 seconds of idle time. WebRTC sends ICE consent-freshness packets every few seconds to keep the path alive
• Network handover. A user moves from Wi-Fi to cellular mid-call. The old NAT binding is gone. WebRTC triggers an ICE restart to gather fresh candidates and re-establish media without dropping the session
• Hairpinning. Two peers behind the same NAT trying to reach each other via their public mappings. Some NATs don’t support this (“no hairpin”), forcing a TURN relay even though both peers are one network hop apart
• IP leak prevention with mDNS. Browsers obfuscate local LAN addresses behind randomized .local mDNS hostnames so that web pages can’t fingerprint the user’s internal network through the WebRTC ICE candidate gathering process
• IPv6 transition with DNS64/NAT64. Mobile networks (especially Apple’s iOS-only IPv6-only test networks) use NAT64 to let IPv6-only clients reach IPv4-only services. WebRTC has to handle the address-family differences

Related glossary terms

• STUN – discovers your public address through a NAT
• TURN – relays media when direct paths fail
• ICE – orchestrates candidate gathering and connectivity checks
• ICE Restart – re-establishes the path after network changes
• P2P – peer-to-peer media topology, what NAT primarily complicates
• mDNS – privacy-preserving local-address obfuscation
• DNS64 / NAT64 – IPv4/IPv6 transition mechanism
• IPv4 and IPv6 – the addressing context that motivates NAT in the first place

Watch: NAT, firewalls and WebRTC

Additional reading

• Do you still need TURN if your media server has a public IP address?
• WebRTC vs WebSockets – covers NAT-traversal differences between the two
• You don’t need an SBC for WebRTC – enterprise-network angle on NAT and firewalls