What is NAT Traversal?

NAT traversal is the set of techniques used to establish communication when one or both endpoints sit behind Network Address Translation. NAT can hide a device's private address and transport port behind a public-side mapping, so another endpoint cannot always initiate traffic directly. NAT traversal discovers usable paths through that translation, tests whether the endpoints can reach each other and, when necessary, uses a relay.

The important distinction is that NAT traversal is not one protocol. Modern real-time applications commonly combine STUN, ICE and TURN. STUN helps discover public-side mappings, ICE coordinates candidate gathering and connectivity checks, and TURN can relay traffic when a direct path cannot be established.

Why is NAT traversal needed?

A typical home router uses NAT (Network Address Translation) so devices using private IPv4 addresses can share the broadband connection's public IPv4 address. Outbound traffic creates translation state. Return traffic can then be mapped back to the correct internal device. The difficulty appears when two applications want direct peer-to-peer communication and one or both sides are behind NAT.

• The private address is not globally routable on the public internet.

• The NAT may allocate a different public-side source port from the local source port.

• An unsolicited inbound packet may not match an existing NAT mapping.

• Different NAT mapping and filtering behaviours can change whether hole punching succeeds.

• A firewall can independently block traffic even when the NAT mapping itself would permit it.

How NAT traversal works

A traversal system tries to learn what addresses and ports might work, exchanges that information through an application-specific signalling mechanism, then tests candidate paths. If a direct path works, traffic can flow peer to peer. If it does not, the application can fall back to a relay.

1. Gather local candidates: the application knows addresses and ports available on its own interfaces.

2. Discover public-side mappings: a STUN server can tell an endpoint the IP address and port from which its request appears to originate.

3. Exchange candidates: the two endpoints exchange possible transport addresses using the application's signalling channel.

4. Run connectivity checks: ICE tests candidate pairs rather than assuming a particular address will work.

5. Select a working path: a successful direct candidate pair is normally preferable.

6. Relay when necessary: if direct connectivity cannot be established, TURN can provide a public relay address and carry the traffic.

What is STUN?

RFC 8489 defines Session Traversal Utilities for NAT. STUN can let an endpoint determine the IP address and port allocated to it by a NAT, perform connectivity checks and help keep NAT bindings alive. The RFC is explicit that STUN is not a complete NAT traversal solution by itself. It is a tool used inside a larger traversal solution.

For example, a laptop might send a UDP packet from 192.168.1.20:50000. The NAT could expose that flow as 198.51.100.25:62000. A STUN response can reveal the public-side 198.51.100.25:62000 mapping to the application. These are documentation addresses used only for illustration.

What is ICE?

RFC 8445 defines Interactive Connectivity Establishment for NAT traversal of UDP-based communication. ICE gathers candidate transport addresses, exchanges them using the application's signalling mechanism, forms candidate pairs and performs STUN connectivity checks to find a working path.

• Host candidates: addresses obtained from local interfaces.

• Server-reflexive candidates: public-side translated addresses discovered using STUN.

• Relayed candidates: addresses allocated on a TURN server.

ICE is therefore the coordinator. It does not simply ask whether NAT exists. It builds a set of possible routes and tests which route can actually carry traffic.

What is TURN?

RFC 8656 defines Traversal Using Relays around NAT. When direct communication is not possible, an endpoint can obtain a relayed transport address on a TURN server. The server then relays traffic between the endpoints.

TURN is extremely useful because a relay on the public internet can provide connectivity even when NAT or firewall behaviour prevents a direct path. The trade-off is that the application traffic now passes through the relay, consuming relay bandwidth and potentially adding network-path latency. For that reason, ICE normally tries direct connectivity first and uses TURN when needed.

STUN vs TURN vs ICE

• STUN: discovers NAT-created address and port information and supports connectivity checks. It does not, by itself, provide a complete traversal solution.

• ICE: gathers candidates, prioritises candidate pairs and performs connectivity checks to choose a working path.

• TURN: provides a relay path when direct endpoint-to-endpoint connectivity cannot be established.

What is NAT hole punching?

Hole punching is a family of techniques in which endpoints create NAT state by sending outbound traffic, then attempt to use the resulting mappings for peer-to-peer communication. The technique is especially associated with UDP because applications can coordinate candidate addresses and send traffic in both directions to establish usable mappings.

Hole punching is not guaranteed. The result depends on NAT mapping behaviour, filtering behaviour, firewall policy, timeouts and whether both endpoints can coordinate the attempt. TURN exists precisely because a direct path cannot always be found.

Does CGNAT make NAT traversal harder?

It can. With CGNAT, the customer's router may perform one layer of NAT while the ISP performs another layer upstream. That extra translation means the customer does not control the public IPv4 mapping at the ISP boundary. Traditional inbound port forwarding on the home router cannot create a forwarding rule through the ISP's CGNAT.

Applications that use ICE, STUN and TURN can still work through many CGNAT environments because they do not rely solely on a manually configured inbound port forward. However, the actual result depends on the access network, NAT behaviour and firewall policy.

NAT traversal and IPv6

IPv6 can remove the need for IPv4 address translation when both endpoints have usable global IPv6 connectivity, but that does not mean every application automatically gains unrestricted inbound reachability. Firewalls still apply policy, and real deployments can be dual stack, IPv4-only on one side or use translation technologies. See the Techie Broadband guides to IPv4 and IPv6 for the addressing differences.

Where do you encounter NAT traversal?

• Voice and video calling where two endpoints benefit from a direct media path.

• WebRTC applications in browsers and real-time communications platforms.

• Online gaming and peer-to-peer game traffic.

• Remote-access and peer-to-peer networking software.

• Some VPN and overlay-network designs that attempt direct peer connectivity before using relays.

NAT traversal should not be confused with a VPN. A VPN creates a protected tunnel or overlay path. NAT traversal is the connectivity problem-solving process that can help endpoints establish the path through NAT in the first place.

Does NAT traversal open your router to the internet?

Not in the simple sense implied by that phrase. Traversal techniques can create or use NAT mappings for specific application traffic, but the behaviour depends on the protocol, the NAT and firewall rules. A successful mapping for one flow does not make every internal device or port publicly reachable.

Why can NAT traversal fail?

• The NAT mapping behaviour prevents the candidate from being reused as expected.

• Filtering rules reject packets from the remote endpoint.

• A firewall blocks the traffic independently of NAT.

• A NAT binding expires before the application refreshes it.

• UDP is restricted or blocked on part of the path.

• The signalling layer exchanges stale or incorrect candidate information.

• The TURN server is unavailable, unreachable or misconfigured.

• Multiple layers of NAT introduce additional constraints.

How to troubleshoot NAT traversal problems

1. Confirm ordinary internet connectivity works before investigating traversal.

2. Identify whether the connection has a public IPv4 address or is behind CGNAT.

3. Check whether the application reports host, server-reflexive and relay candidates.

4. Confirm the configured STUN and TURN servers are reachable.

5. Check local firewall rules and router security settings.

6. Test whether a TURN relay works when direct connectivity fails.

7. Compare behaviour on another network, such as a different fixed connection or mobile connection.

8. Review application logs for ICE candidate-pair selection and failed connectivity checks.

Techie Broadband diagnostic interpretation: if a session works only when a TURN relay is forced, the application has proved that end-to-end communication is possible through the relay. It has not proved why the direct path failed. NAT mapping behaviour, filtering, firewall policy and network restrictions still need to be separated.

Does NAT traversal affect broadband speed or latency?

NAT traversal itself is primarily about reachability, not increasing line speed. A direct peer-to-peer path may avoid the extra network distance of a relay. A TURN-relayed path sends the application traffic through the TURN server, so performance depends on the route to that server, its capacity and the route onward to the peer.

On a fast FTTP or multi-gigabit connection, the broadband access link may not be the limiting factor. The application, router, firewall, relay capacity and wider internet path can all matter. A successful traversal method does not guarantee low latency, high throughput or zero packet loss.

Common NAT traversal misconceptions

• STUN is not a complete NAT traversal solution by itself.

• TURN is not the same as STUN. TURN relays application traffic.

• ICE is not a relay. ICE coordinates candidates and connectivity checks.

• NAT traversal does not guarantee a direct peer-to-peer path.

• CGNAT does not automatically break every real-time application.

• IPv6 does not mean firewalls disappear.

• A working TURN session does not prove that direct NAT traversal should also work.

Key takeaway

NAT traversal is the practical process of getting endpoints behind NAT to communicate. STUN helps reveal public-side mappings, ICE gathers and tests possible paths, and TURN provides a relay when a direct route cannot be established. For UK broadband users, the important variables are not only the home router but also CGNAT, firewall policy, IPv4 and IPv6 availability, and the application's own traversal implementation.

NAT traversal FAQs

Is NAT traversal the same as port forwarding?

No. Port forwarding is a manually or automatically created inbound mapping on a NAT device. NAT traversal is a broader set of techniques for discovering and establishing usable paths through NAT, often without relying on a fixed manual port forward.

Is STUN enough for NAT traversal?

No. RFC 8489 explicitly describes STUN as a tool rather than a complete NAT traversal solution. Applications commonly use it as part of ICE and may use TURN when a relay is required.

Why is TURN needed?

TURN is needed when a direct path cannot be established. It gives an endpoint a public relay address and carries traffic between the peers through the TURN server.

Does CGNAT stop WebRTC and online calling?

Not necessarily. Many applications use ICE, STUN and TURN specifically to cope with NAT. CGNAT can make direct inbound connectivity harder, but a relay can still provide a working path when supported.

Does IPv6 eliminate NAT traversal?

Native end-to-end IPv6 can remove the IPv4 NAT translation problem, but firewall policy, mixed IPv4/IPv6 environments and application behaviour still affect connectivity.

To explore the related technical concepts used in this NAT Traversal guide, visit our broadband terminology guide.