Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

TCP hole punching is a network technique that lets two devices behind Network Address Translation (NAT) try to create a direct TCP connection by coordinating their addresses and starting connection attempts toward each other at nearly the same time. It can work when the NATs and TCP implementations support the required behavior, but it is not guaranteed; systems such as ICE can test possible paths, and TURN can relay traffic if a direct connection fails.

How TCP hole punching works

A NAT lets devices on a private network share a public-facing address. It creates state for traffic that leaves the network, and that state can allow replies to return. An unsolicited inbound connection, by contrast, may have no matching state and be blocked.

Hole punching aims to have each peer create the necessary NAT state by making an outbound TCP connection attempt toward the other peer. A rendezvous or signaling service helps the peers discover address information and coordinate those attempts. If the attempts and network behavior line up, the peers can communicate directly; the signaling service does not have to carry the application data on that direct path.

  1. Coordinate: The peers contact a rendezvous service and exchange candidate address information.
  2. Attempt connections: Each peer initiates a TCP connection toward the other, close enough in time for TCP simultaneous-open behavior to be relevant.
  3. Check the path: The peers determine whether the connection works and can carry their traffic directly.

The exact signaling protocol and sequence vary by implementation. The essential idea is coordinated outbound attempts, not a guarantee that any device can accept an ordinary inbound connection through any NAT.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Why both peers attempt to connect

TCP normally has one side actively initiate a connection while the other listens. Hole punching instead relies on simultaneous open: both peers attempt to open a TCP connection toward one another. That behavior can help the connection succeed when neither peer can simply be reached through a conventional inbound connection. RFC 6544 describes TCP candidate types for ICE, including active, passive, and simultaneous-open roles.

The peers need to coordinate their attempts and use the relevant candidate information. Simply knowing a peer’s public address is not enough: NAT state, filtering rules, timing, and TCP behavior all affect whether packets can pass and a connection can form.

When TCP hole punching works—and when it does not

Success depends on the complete path and the implementations at both ends. RFC 5128 identifies endpoint-independent mapping as a condition for the hole-punching method it describes. With endpoint-dependent mapping, a NAT may create a different public mapping depending on the remote endpoint, making reuse or prediction of the needed mapping difficult. Filtering behavior, firewalls, and support for TCP simultaneous open can impose additional constraints.

  • More favorable: The NAT behavior and TCP stacks allow the coordinated attempts and resulting packets to use compatible state.
  • Less favorable: Endpoint-dependent mapping, restrictive filtering, firewall policy, or incompatible simultaneous-open behavior prevents the peers from establishing a direct path.
  • Not predictable from a single rule: NAT devices do not all behave alike, so the technique should be treated as an attempt rather than a universal traversal method.

How TCP hole punching fits into ICE and TURN

TCP hole punching is one possible direct-connectivity technique within a broader NAT traversal process. ICE gathers and checks candidate paths between peers. RFC 6544 extends ICE with TCP candidates, including active, passive, and simultaneous-open types, so implementations can test TCP-based options as part of connectivity checks.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

If a direct path cannot be established, a system can use TURN to relay traffic. The peers communicate through a TURN server rather than directly with one another. RFC 8656 describes TURN relay operation and its role in the larger ICE approach: ICE searches for a direct path using hole-punching techniques first and uses a TURN server when a direct path cannot be found. A relay is therefore a fallback path, not another name for hole punching.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

TCP hole punching versus relaying

Approach Traffic path What it depends on
TCP hole punching Directly between the peers, if connection attempts succeed Compatible NAT mapping and filtering behavior, coordinated attempts, and suitable TCP behavior
TURN relay Through a TURN server between the peers A usable relay allocation and server; it can be used when direct connectivity cannot be found

Which path is available depends on the networks and implementation. The cited standards establish the direct-versus-relayed distinction, but do not establish a universal success rate, latency difference, or operating cost for a particular deployment.

Standards that define the pieces

  • RFC 5128 surveys peer-to-peer communication across NATs, including TCP and UDP hole punching.
  • RFC 6544 defines TCP candidates for ICE, including active, passive, and simultaneous-open types.
  • RFC 8656 defines TURN and explains its role as a relay when a direct path cannot be found.
  • RFC 5596 discusses TCP hole punching and the coordination involved.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.