What's so hard about p2p Hole Punching?

Question

I am trying to experiment with some p2p networking. Upon doing some research, one of the biggest obstacle I learnt is "What if a client is behind a NAT/Firewall", later on I discovered about Hole Punching but that it is not always guaranteed to work.

As far a I understand, I don't understand why it might fail, This is what I know so far:

---

Based on the diagram above, this is how I understand how a successful connection can be established.

1. Alice joins the network (1) by creating connection to a directory-server. When this happens, Alice's NAT creates a mapping from her public ip to her local ip.
2. The directory server receives the connection and store Alice's public ip:port in the directory
3. Bob does the same (2), Joins the network and publishes his ip:port in the directory
4. Alice wants to communicate with bob. So she looks up Bob's ip:port from the directory. (3)
5. Alice sends data on Bob's ip:port which she got from the server. (5)
6. Since Bob also has a mapping from is ip:port to his local ip:port, the NAT simply forwards any data received on Bob's public ip:port to his computer.
7. Same works for Alice

   ---

   I hope I was clear in my explanation of what I understand. My question is, what is so hard or unreliable about this? i must be clearly missing something. Can you explain me what it is?

Answer 1

I think understanding how the Hole Punching really works would assist to get into why it may fail.

It was first explored by Dan Kagel, read here. In this technique, both peers are generally assumed to be behind two different NATs. Both peers must be connected to an intermediate server called a Rendezvous/Signaling server; there are many well-known Rendezvous protocols and SIP (RFC 3261) is the most famous one. As they are connected to the server, they get to know about each other’s public transport addresses through it. The public transport addresses are allocated by the NATs in front of them. The Hole Punching process in short:

1. Peer 1 and Peer 2 first discover their Public Transport Addresses using STUN Bind Request as described in RFC 8589.
2. Using a signaling/messaging mechanism, they exchange their Public Transport Addresses. SDP(Session Description Protocol)[16] may be used to complete this. The Public Transport Address of Peer 1 and Peer 2 will be assigned by NAT 1 and NAT 2 respectively.
3. Then both peers attempt to connect to each other using the received Public Transport addresses. With most NATs, the first message will be dropped by the NAT except for Full Cone NAT. But the subsequent packets will penetrate the NAT successfully as by this time the NAT will have a mapping.

NAT can be of any type. If the NAT is, let's say, Symmetric NAT RFC 8489, Hole Punching won’t be possible. Because only an external host that receives a packet from an internal host can send a packet back. If this is the case, then the only possible way is Relaying.

Learn more about the current state of P2P communication: read RFC 5128.

Answer 2

One problem is that the NAT mappings in Alice's NAT server may time out, either after a fixed time, or after a period of inactivity.

A second potential problem is that the NAT server could make the restriction that Alice's NAT mapping is only "good" for TCP connections established by Alice, or connections between Alice and the initial IP "she" connected to. (In other words, direct communication between Alice & Bob may be blocked.)

And so on.

The problem is that the behaviour of a NAT server is highly dependent on how the managing organization's configuration / policy decisions. Many of these decisions could mean that your particular P2P usage pattern won't work reliably ... or at all.

---

So then is my whole idea about hole punching wrong?

No. It just means that it won't always work.

Answer 3

Possibly the biggest problem in NAT holepunching is lack of port consistency. For your implementation to work, at least one of the two NATs must support it.

Port consistency is where the same (local ip, local port) is mapped to the same (external ip, external port) regardless of the target (destination ip, destination port). Without this, the port seen by the directory server is not helpful to the client since it will not be the same port the clients will need to talk to each other.

(Note that this is a weaker requirement than port preservation, where external port == local port.)

Unfortunately for P2P communication, most NATs are some flavor of Symmetric NAT and do not have consistent port mappings.

Answer 4

First of all there are 2 types of hole punching 1.UDP hole punching 2.TCP hole punching

UDP hole punching success rate is 82% TCP hole punching success rate is 64% I have done many UDP hole punching experiments and they were mostly all successful but not same in the case of TCP hole punching.

The reason behind the failure of TCP hole punching is only the router NAT table. I will try to explain my best:

Client 1 --> connect(client2) --Internet-- connect(client1)<-- Client 2

Now if Client1 **SYN Packet**** reaches to the client2 and **client2 **SYN packet wasn't released** , the ROUTER of client2 can do 2 things: 1. send RST packet back as connection refused to client1. 2. drop packet immediately and no reply send to client1.

If this happens no connection will be established.

I can only suggest a solution that time difference between connect call from both the client should be very less. The connect call difference should be in milli-seconds

TIP: if you are in local network , put disable your firewall

for ubuntu user : sudo ufw disable

Answer 5

Firewalls are typically stateful. Bob (2) establishing communications with the outside directory server sets up a rule in his NAT server that allows Bob and the directory server to communicate. When the NAT server sees packets from Alice, it rejects/drops them because it hasn't seen Bob establish communications with Alice.