What Is UDP Hole Punching?

In computer science, UDP hole punching refers to a commonly used NAT traversal technology.

by

Assume that there are two hosts in their respective private networks: A and B; N1 and N2 are the NAT devices of the two networks and have IP addresses P1 and P2 respectively; S is a well-known and used from anywhere in the world A public server that can access the obtained IP addresses.

Step 1: A and B establish UDP connections with S, respectively; NAT devices N1 and N2 create UDP transition states and assign temporary external port numbers.

Step 2: S checks the UDP packets to see if the ports A and B are being used (otherwise N1 and N2 should be applied with random port assignment, which will make routing verification more troublesome).

Step 3: If the ports are not randomized, then A and B select ports X and Y respectively and inform S. S will let A send a UDP packet to P2: Y, and let B send a UDP packet to P1: X.

Step 4: A and B directly contact each other's NAT device through the converted IP address and port. ^[1]

For symmetric NAT devices (also known as bidirectional NAT) common in large corporate networks, UDP hole punching does not work. In symmetric NAT, the NAT mapping associated with the connection of the famous STUN server is limited to receiving data from well-known servers, so the NAT mapping seen by well-known servers is not useful information for endpoints.

In a more detailed method, the two hosts will start sending to each other, using multiple attempts. On restricted cone NAT, the first packet from other hosts will be blocked. After that, the NAT device has a record of sending a packet to another machine and letting any packet come from that IP address and port number. This technology is widely used in point-to-point software and Internet Protocol voice calls. It can also be used to assist in establishing a virtual private network running over UDP. The same technology is sometimes extended to Transmission Control Protocol (TCP) connections, but with a lower success rate, because the TCP connection flow is controlled by the host operating system, not the application, and the serial number is chosen randomly. ^[2]