{"id":1047,"date":"2026-05-18T15:55:50","date_gmt":"2026-05-18T08:55:50","guid":{"rendered":"https:\/\/liveapi.com\/blog\/nat-traversal\/"},"modified":"2026-05-18T15:56:32","modified_gmt":"2026-05-18T08:56:32","slug":"nat-traversal","status":"publish","type":"post","link":"https:\/\/liveapi.com\/blog\/nat-traversal\/","title":{"rendered":"What Is NAT Traversal? How It Works, Techniques, and Use Cases"},"content":{"rendered":"Reading Time: <\/span> 14<\/span> minutes<\/span><\/span>

More than 90% of consumer devices sit behind a router that performs Network Address Translation (NAT). That single fact is the reason peer-to-peer video calls, multiplayer games, and remote desktop tools can’t just send packets to each other the way two servers in a data center can. NAT traversal is the set of techniques that gets around this restriction so two devices on different private networks can still establish a direct connection \u2014 or at least a working one.<\/p>\n

This guide walks through what NAT traversal is, why it matters, the core techniques (STUN, TURN, ICE, UDP hole punching, port mapping), how it shows up in IPsec and WebRTC, and how to think about it when you’re building real-time video and streaming applications.<\/p>\n

What Is NAT Traversal?<\/h2>\n

NAT traversal is a networking technique for establishing and maintaining IP connections across gateways that perform network address translation. In plain terms: it’s the collection of tricks that lets a device behind a NAT receive incoming connections, even though the NAT is designed to block them.<\/p>\n

A NAT device translates many private IP addresses inside a local network (like 192.168.1.x<\/code>) into a single public IP address on the open internet. It does this by rewriting source addresses and ports as packets leave the network, and reversing the mapping when responses come back. The side effect is that the outside world doesn’t know how to reach a specific device inside \u2014 it only sees the NAT’s public address.<\/p>\n

NAT traversal solves three core problems:<\/p>\n

    \n
  1. Discovery<\/strong> \u2014 Figuring out the public IP and port that a NAT has assigned to your local socket.<\/li>\n
  2. Hole punching<\/strong> \u2014 Getting the NAT to permit incoming packets from a specific remote peer.<\/li>\n
  3. Fallback<\/strong> \u2014 Relaying traffic through a public server when a direct path isn’t possible.<\/li>\n<\/ol>\n\n\n\n\n\n\n\n\n\n
    NAT vs. NAT Traversal<\/th>\nNAT<\/th>\nNAT Traversal<\/th>\n<\/tr>\n<\/thead>\n
    Goal<\/td>\nShare one public IP across many devices<\/td>\nAllow connections through NAT to reach internal hosts<\/td>\n<\/tr>\n
    Direction<\/td>\nOutbound by default<\/td>\nInbound or peer-to-peer<\/td>\n<\/tr>\n
    Operates on<\/td>\nRouter\/firewall<\/td>\nEndpoints + helper servers<\/td>\n<\/tr>\n
    Common protocols<\/td>\nNAT44, NAT64, CGNAT<\/td>\nSTUN, TURN, ICE, UPnP, NAT-PMP, PCP<\/td>\n<\/tr>\n
    Visible to apps<\/td>\nNo (transparent)<\/td>\nYes (signaling is required)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    According to the NAT traversal article on Wikipedia<\/a>, the techniques are standardized across more than a dozen IETF RFCs covering NAT terminology, IPsec compatibility, hole punching, and ICE.<\/p>\n

    Why NAT Is a Problem for Direct Connections<\/h2>\n

    A NAT is, in effect, a stateful firewall. It tracks every outbound flow and creates a mapping entry: “internal 10.0.0.5:54321<\/code> \u2194 external 203.0.113.10:62000<\/code> for destination 198.51.100.7:443<\/code>.” Packets that arrive on the public side without a matching mapping are dropped.<\/p>\n

    This works fine for client-server traffic. Your browser opens an outbound connection to a web server, the NAT creates a mapping, and replies flow back through the same hole. It breaks down for three scenarios:<\/p>\n