NAT hole punching

Hi there,

I'm trying to understand NAT hole punching. I've already read

[1] "Peer-to-Peer Communication Across Network Address Translators"
http://www.bford.info/pub/net/p2pnat/

[2] "TCP Connections for P2P Apps: A Software Approach to Solving the
NAT Problem"
http://citeseerx.ist.psu.edu/viewdoc...=rep1&type=pdf

I'd like to reproduce the sequential approach in [2] (or short 4.5 [1]).
To do that I played around with netcat.

On the broker B I listened with `nc -v -v -l -p 3456` (or just `nc -v
-v -l 3456` with more recent netcats). Then I successively connected to
the port. First from X with `nc -p 5678 B 3456`. Then from Y with
`nc -p 5679 B 3456`. So in this step I gathered the IP addresses and the
mapping from X's port 5678 on X's NAT router (let the router be X*) and
Y's port mapping respectively (let Y's router be Y*).

I learned that both NAT routers follow the port preservation design¹, so
the sockets were created from 5678 on X* and from 5679 on Y*
respectively.

I did the hole punching (or better: tried to do) on X with
`nc -p 5678 Y* 5679` and on Y with `nc -p 5679 X* 5678` (two holes
better than one :-) I have repeated this step a few times, but whenever
I created a listening socket on X with `nc -l -p 5678` and tried to
connect from Y with `nc -p 5679 X* 5678` it didn't work. The other way
(from Y to X) didn't work either.

I know I didn't strictly follow the procedure in [2], but I'd still
like to know why it didn't work. Could someone enlighten me?

Regards,
Tobias

¹ see http://en.wikipedia.org/wiki/Network...ss_translation

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktkO/gACgkQ5jrP7hWxSO8kbgCeIbaDJqq+d8CTW5HbqmdZC9EF
Zx4An3uco8ewxouWecgXqKtxy8QF+b9E
=7hw5
-----END PGP SIGNATURE-----

David Schwartz wrote:
> On Jan 30, 6:02Â*am, Tobias Nissen <t...@movb.de> wrote:
>> I know I didn't strictly follow the procedure in [2], but I'd still
>> like to know why it didn't work. Could someone enlighten me?
>
> You never punched a hole. You simply tried to reach A from B, which
> won't work because of B's NAT -- and you tried to reach B from A,
> which won't work because of A' s NAT.

I don't remember where, but I read somewhere, that by doing so the NAT
devies learn of A's and B's intentions to communicate with each other.
So if let's say A's NAT sees A trying to connect to B:5679 from A:5678,
it assumes that it is OK for B to connect to A.

But this doesn't seem to be the way at least my NAT-devices work. Or
is it generally out of the question that this could work?

> If you tried both at the same
> time, it could work if both B and A's NAT preserve source ports. But
> the usual approach is to get both B and A to establish a connection to
> a computer that is not behind NAT and then use the NAT entries thus
> established to allow B and A to connect to each other directly.

With that SO_REUSEADDR magic? IOW I can't do it with netcat, right?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktlbtIACgkQ5jrP7hWxSO9bMACeILYrb+Eo1o gJS5zBzdLtM4lQ
VncAoM5KJRGXHOsqLdB9bN9lXo2T6U6N
=i7fz
-----END PGP SIGNATURE-----

David Schwartz wrote:
> On Jan 31, 3:51Â*am, Tobias Nissen <t...@movb.de> wrote:
>> I don't remember where, but I read somewhere, that by doing so the
>> NAT devies learn of A's and B's intentions to communicate with each
>> other. So if let's say A's NAT sees A trying to connect to B:5679
>> from A:5678, it assumes that it is OK for B to connect to A.
>
> Right, but how does A learn B's source port? How does B learn A's
> source port? You need some common intermediary that both A and B
> connect to.

I know, that's why I have an intermediary. It's called B (other B than
yours), see my original posting.

>> But this doesn't seem to be the way at least my NAT-devices work. Or
>> is it generally out of the question that this could work?
>
> See if your NAT devices change the source ports.

They don't, see my OP :-)

>>> If you tried both at the same
>>> time, it could work if both B and A's NAT preserve source ports.
>>> But the usual approach is to get both B and A to establish a
>>> connection to a computer that is not behind NAT and then use the
>>> NAT entries thus established to allow B and A to connect to each
>>> other directly.
>
>> With that SO_REUSEADDR magic? IOW I can't do it with netcat, right?
>
> You have to actually do that NAT traversal or hole punching, and you
> need an intermediary to do it in most cases. Otherwise, A and B have
> on way to learn their own source ports.

I know my OP is a bit hard to read with all the involved ports and
hosts, but it's all in there.

My main question is: Why doesn't the hole punching work with netcat?
Does it always have to be the same socket that is reused again and
again (for the connection to the intermediary, for the hole punching and
for the direct connection)?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktlqtkACgkQ5jrP7hWxSO+UQgCgpYBgh0Fg8q quwQxf0IAQz4WC
nvsAoLkLvOysCw2KClg3MX6U7FqzLsj7
=5qE1
-----END PGP SIGNATURE-----

Dear All,

I'm afraid I missed one essential thing in the discussion concerning NAT
hole punching, but may be I'm wrong: you need UDP packets.

TCP connections have to be opened and closed, so
as soon netcat did it's job, the connection is put into state closed and
the connection is forgotten.

UDP is stateless, as soon A sends an UDP packet,
there is an open channel from the router to A waiting for response, until
it times out.

Assume that hosts A and B are behind NAT, but want to communicate,
and a public intermediate host C is available.

A sends an UDP packet to C, and creates an open channel on the router
waiting for response.

C informs B about the parameters of this A-channel, and B uses this open
channel to send packets to A.

C informs A about the parameters of B, and now A en B can communicate
directly via the holes on both routers.

So I think you definitively need "-u" as additional option in your netcat
tests.


Kind Regards,








Tobias Nissen wrote:

> David Schwartz wrote:
>> On Jan 31, 3:51 am, Tobias Nissen <t...@movb.de> wrote:
>>> I don't remember where, but I read somewhere, that by doing so the
>>> NAT devies learn of A's and B's intentions to communicate with each
>>> other. So if let's say A's NAT sees A trying to connect to B:5679
>>> from A:5678, it assumes that it is OK for B to connect to A.
>>
>> Right, but how does A learn B's source port? How does B learn A's
>> source port? You need some common intermediary that both A and B
>> connect to.
>
> I know, that's why I have an intermediary. It's called B (other B than
> yours), see my original posting.
>
>>> But this doesn't seem to be the way at least my NAT-devices work. Or
>>> is it generally out of the question that this could work?
>>
>> See if your NAT devices change the source ports.
>
> They don't, see my OP :-)
>
>>>> If you tried both at the same
>>>> time, it could work if both B and A's NAT preserve source ports.
>>>> But the usual approach is to get both B and A to establish a
>>>> connection to a computer that is not behind NAT and then use the
>>>> NAT entries thus established to allow B and A to connect to each
>>>> other directly.
>>
>>> With that SO_REUSEADDR magic? IOW I can't do it with netcat, right?
>>
>> You have to actually do that NAT traversal or hole punching, and you
>> need an intermediary to do it in most cases. Otherwise, A and B have
>> on way to learn their own source ports.
>
> I know my OP is a bit hard to read with all the involved ports and
> hosts, but it's all in there.
>
> My main question is: Why doesn't the hole punching work with netcat?
> Does it always have to be the same socket that is reused again and
> again (for the connection to the intermediary, for the hole punching and
> for the direct connection)?