UDP Hole puching technology: Building UDP connections through firewalls

Drilling on a fireproof wall "UDP Hole puching": Building a UDP connection through a firewall

Do you know how popular Peer-to-peer software and IM software makes two computers that are located behind different firewalls directly talking to each other? SIP is a kind of course, there is a widely used in this paper is the introduction of the UDP Hole puching technology.

To make it easier to tell, let's assume that there is a network topology:

IP=A.A.A.A ip=1.1.1.1

HostA----------Firewalla---------|

|

Server IP=S.S.S.S

|

HostB----------FIREWALLB---------|

Ip=b.b.b.b ip=2.2.2.2

To apply this technique, the following conditions must be met:

1) Hosta and HostB are connected to the server via NAT through Firewalla and FIREWALLB respectively.

2 Firewalla and FIREWALLB are satisfied with this feature, that is, from the same IP Port packets, regardless of the destination IP is how many, will nat into the same ip+port, for example:

Hosta through UDP port 1234 access to host S1, the firewall will packet Nat to 1.1.1.1:5668 (for example), then hosta through UDP port 1234 access to host S2, the firewall will still be the packet Nat 1.1.1.1:5668. The good news is that Nat now basically has this feature.

Hosta now connects to the server's 5555 port with UDP port 1111, HostB connects to server 5555 ports with Port 2222, and Hosta from 1.1.1.1:9676 (Firewalla Nat passed). , HostB is from 2.2.2.2:6573. When Hosta wants to connect directly to HOSTB, it does this:

1 use UDP port 1111 to send a packet to 2.2.2.2:6573, note must use port 1111 Oh, this packet will be Firewalla nat into 1.1.1.1:9676-> 2.2.2.2:5668 (Don't ask why, Look at the front facing the firewall requirements first); Never expect HostB to receive this packet, because when the packet arrives at FIREWALLB, Firewallb is confused and does not know who the 1.1.1.1:9676-> 2.2.2.2:6573 packet should be transferred to. Of course, the package is discarded and an ICMP packet is returned saying that port does not exist. However, we still get something we want, that is, we successfully told Firewalla "if there are 2.2.2.2:6573-> 1.1.1.1:9676 packets, please forward to a.a.a.a:1111", this is a hole!!

2 Next, as you imagine, hosta through the server relay, tell HOSTB, with Port 2222 send a packet to 1.1.1.1:9676,HOSTB complied with, and this package will be firewallb Nat 2.2.2.2:6573- > 1.1.1.1:9676. This reply packet also drilled a hole in the firewallb, all 1.1.1.1:9676-> 2.2.2.2:6573 packets will be forwarded to the b.b.b.b:2222, when the packet arrives at Firewalla, Firewalla was pleased to send the 2.2.2.2:6573-> 1.1.1.1:9676 packets to a.a.a.a:1111.

3 finished, Hosta and HostB began to have a pleasant conversation.

It's very simple, isn't it? But the implementation should also pay attention to a few points, otherwise you do not know why always do not connect:

1 in step 1, the port does not exist ICMP is a killer, at least for Linux on the iptables NAT is the case, because Firewalla received this ICMP will close the hole in the drill, Find ways to not let firewallb send this ICMP or let Firewalla lose this ICMP bar;

2 time problem, step 1 in the Firewalla open hole is a time limit, usually 30-60 seconds, if the timeout did not receive 2.2.2.2:6573-> 1.1.1.1:9676 bag, the hole will automatically close, the same step 2, Hosta should also send a packet to B in time to ensure that the hole in the FIREWALLB will not be closed due to timeout. It is worth mentioning that most NAT firewall will be seen in and out of two-way packets to extend the time to close the hole, the Linux default setting will be extended to 3 minutes.

3 Hosta can not connect to the HOSTB, does not mean that HostB must not even hosta, reverse the direction of the test may have unexpected surprises.