Nat Punchthrough understanding P2P concept [closed]

Question

So, i have been reading up on NAT-Punchthrough. I seem to be getting the idea, but i have a hard time implementing it, and i feel that i am missing a step here. Testing this functionality is kind of hard because i have little control over the environment when it comes to a internet based connection.

I have a SQL server to run as my "facilitator" it keeps the external address of both server and client, and their port as seen by the outside.

Here are steps so far: - I connect to my SQL server through a web request (PHP script) that stores server/client IP/PORT - When both are known, both client and server attempt connecting (server hosts on a set port, client connects over a set port) - Nothing significant happens

There are 2 unknowns here, and i would like to check one with you. Is it true that NAT-Punchthrough requires that i do the first step with the exact (internal/LAN) port i plan to connect with in the step after that?

If so, i don't know how exactly my server works underwater, so it might need more ports then my initial given static port to connect over, but that at least gives me a hint.

If anyone has more documentation on this then me, please let me know.

Sources:
Programming P2P application
http://www.mindcontrol.org/~hplus/nat-punch.html

Answer 1

NAT punch through works on the principle of educated guesswork. It is usually used to create connections with devices that do IP Masquerading. This is the technology used in most home internet modems to the point that NAT has become interchangeably used to refer to IP Masquerading.

When you connect out from a device which is behind a NAT system like a home modem. You have no control of the port that will be used for the outbound connection to the Internet. However many of these devices allocate ports using specific patterns. For example, incremental numbers.

NAT punch through involves trying to directly connect two source systems that are both behind independent NAT devices. A third system, your "facilitator" acts as a detector for the origin port numbers currently being assigned by both NAT devices on outbound connections. The origin port number, along with the IP address is then sent to the other parties.

So now the clever bit to answer your question. Both systems that want to directly connect, start trying to communicate to the other. They try connecting to a range of ports, around the known port number detected by the facilitator. This is the guesswork.

It is important that both source systems start trying to connect as this will establish NAT sessions in the local devices that allow traffic from the Internet in. If either source device correctly guesses one of those NAT session port numbers, then a connection is established.

In reality, engineers from organisations that have use for NAT punch through have probably spent some time examining the more popular NAT port allocation algorithms and tuning their software. If you have control of connections through your NAT devices, then it would be fairly easy to set up some tests and see how the port numbers change between connections to different servers.