Principles of UDP-based NAT firewall penetration

Do you know how the popular P2P software and IM software allow two computers behind different firewalls to talk directly? Of course, SIP is one type, and the UDP hole Punching Technology introduced in this article is also widely used.
For ease of illustration, we assume there is a network topology:

IP = A. IP = 1.1.1.1
Hosta ---------- firewalla --------- |
|
Server IP = s.s.s. s
|
Hostb ---------- firewallb --------- |
IP = B. B. B IP = 2.2.2.2

The following conditions must be met when using this technology:

1) Hosta and hostb connect to the server through firewalla and firewallb respectively through NAT and UDP

2) Both firewalla and firewallb meet the following requirements: packet from the same IP address and port, regardless of the destination IP address, will be Nat to the same IP address and port. For example:

When Hosta accesses host S1 through UDP port 1234, the firewall will Nat the packet to 1.1.1.1: 5668 (for example). When Hosta accesses host S2 through UDP port 1234, the firewall still translates the packet into 1.1.1.1: 5668. Fortunately, the current Nat basically has this feature.

Now, Hosta uses UDP port 1111 to connect to port 5555 of the server, and hostb uses port 2222 to connect to port 5555 of the server. In the server's opinion, Hosta comes from 1.1.1.1: 9676 (firewalla Nat has passed ), hostb is from 2.2.2.2: 6573. When Hosta wants to directly connect to hostb, it does this:

1) Send a packet to 2.2.2.2: 1111 using UDP port 6573. Be sure to use port 1111. This packet will be converted to 1.1.1.1: 9676 by firewalla nat-> 2.2.2.2: 5668 (Don't ask why, look at the requirements of the firewall before); never expect hostb to receive this packet, because when the packet arrives at firewallb, firewallb is confused, it does not know who to transfer the packet 1.1.1.1: 9676-> 2.2.2.2: 6573. Of course, this packet will be discarded and returned to an ICMP packet saying the port does not exist. However, we still get something we want, that is, we successfully told firewalla
"If you have a packet 2.2.2.2: 6573-> 1.1.1.1: 9676, forward it to a. A. A. a: 1111". This is a hole !!

2) Next, as you think, Hosta uses the server to send a packet to 1.1.1.1: 2222 using port 9676, and hostb will handle it, in addition, this package will be converted into 2.2.2.2: 6573-> 1.1.1.1: 9676 by firewallb Nat. The reply packet also has a hole in firewallb. All packets 1.1.1.1: 9676-> 2.2.2.2: 6573 will be forwarded to B. B. B. b: 2222. When the data packet reaches firewalla, firewalla is happy to forward the data packet 2.2.2.2: 6573-> 1.1.1.1: 9676 to. a. a. a: 1111.

3) Now, Hosta and hostb have a pleasant conversation.

Is it easy? However, pay attention to the following points during implementation. Otherwise, you do not know why the connection fails:

1) in step 1, ICMP, which does not exist in the port, is a killer, at least for Nat using iptables in Linux, because firewalla will close the hole just drilled in when it receives the ICMP packet, try to prevent firewallb from sending this ICMP message or let firewalla discard this ICMP message;

2) time problem. Step 1 has a time limit on the holes opened on firewalla, usually 30-60 seconds. If it times out, you will not receive 2.2.2.2: 6573-> 1.1.1.1: 9676 of the packages will be automatically closed. After step 2, Hosta should also send a packet to B in time to ensure that the holes on firewallb will not be closed due to timeout. It is worth mentioning that most Nat firewalls will extend the time to close the holes after seeing inbound and outbound data packets. The default setting in Linux will be extended to 3 minutes.

3) Hosta cannot be connected to hostb. It does not mean that hostb cannot connect to Hosta. It may be an unexpected surprise to try again.