Udp hole and port bounded cone NAT

I would like to understand how udp hole punching works when two hosts, each of which behind the port limited by the NAT cone, establish a connection.

As I understand it, this happens in several stages and includes three hosts.

Host A and host B are behind a narrow NAT cone.

Host C is a server that can receive packets from hosts A and B.

  • A sends the packet to C.
  • C receives a packet from A and determines the external address: port
  • B sends the packet to C.
  • C receives a packet from B and defines B an external address: a pair of ports
  • C sends an external address: port B to A
  • C sends an external address: port A to B
  • A sends packet_1 to B external address
  • B sends packet_2 to an external address

Questions:

How does A behind a narrow NAT cone receive a packet from B, which also lies behind a restricted NAT cone?

Limited NAT cone NAT does not allow packets in which a pair of source addresses: the port does not match the destination address: port is a pair of packets sent to it that must be received. Why do other packets sent between A and B come in and B?

Is it because NAT with a limited port treats packet_2 as a response from B?

So package_1 will be lost, but package_2 will reach B. Am I right?

Thanks in advance.

+4
source share
4 answers

FYI, here's a document that addresses your questions and provides a detailed overview of NAT. A PDF version is available here .

+2
source

Firstly, the bounded cone nat means that if A is talking to C, B cannot use the hole punched between A and C to communicate with A, assuming B is not behind nat. Meaning, nat traversal does not work in this case.

How can A behind a reconstructed NAT cone receive a packet from B which is also behind a restricted NAT cone?

In this case, this is a different situation called a hairpin. In other words, can B behind nat use A translated address due to nat? Some nats handle this case correctly, others do not.

In your case, even if your nat handles the studs correctly, B packets will not be redirected due to the "limited cone". So the result is the same.

Why do other packets sent between A and B come in and B?

They will not be in your case.

+1
source
A sends packet_1 to B external address B sends packet_2 to A external address How can A behind the restricted cone NAT receive a packet from B which is also behind the restricted cone NAT? Is it because the port restricted cone NAT considers packet_2 as the response from B? So packet_1 will be lost but packet_2 arrives to B. Am I right? 

You are absolutely right, please read about how skype works , this is what you are looking for

0
source

I wrote one: PyPunchP2P . See if anyone can use it.

0
source

Source: https://habr.com/ru/post/1379448/


All Articles