So I was just reading about hole punch techniques for UDP and TCP. I read that TCP hole punch can easily be accomplished if a UDP connection has already been established. So here is my theoretical setup. I have two clients A and B both behind a NAT. They do not have a server to help them with the hole punch. Both have dynamic dns set up so that the other client can be hard coded to point to the others external address, also both are hard coded to use the same internal port, which we will say for example is 22321. Now these clients know that if they are both started and not connected that they want to connect so once every minute on the minute they send a UDP datagram to the other client to every single port, starting with the highest ports since my guess is a NAT will be inclined to use ports above 49152 as those are the dynamic ports. After each has done this there will be a record entered into the NATs state. If the clients are lucky then one of the two clients will hit the others external port after it has been opened by the NAT, and the datagram will get through and the listening client could then notify the sending client of the successful connection. If they were not so lucky then the clients just need to repeat the process, this time each starting from opposite ends to cut the time in half, when one gets through to the other then the receiver notifies the sender that the connection has been established. Could this methodology work? Or perhaps even be simplified by tracking the RST responses from the NAT?
We have clients A and B which are behind a NAT and want to communicate. both clients are listening on UDP port 22321 and both clients know the others global IP address, we will say that A has an ip address of 1.1.1.1 and B has a global ip address of 2.2.2.2. So A sends a packet to 2.2.2.2 on every single port, the contents of which need be basically nothing, for every single packet that passes through the NAT the NAT will change the outgoing IP from A's local address i.e. 192.168.1.16 to the global address 1.1.1.1. As the NAT forwards this packet to client B it creates a state entry for each of those packets so that if a packet is recieved from 2.2.2.2 on any of those ports it will know to forward it to client A (192.168.1.16) on port 22321. All of those packets would reach B's NAT at 2.2.2.2 and be discarded as unsolicited packets. Client B does the exact same process targeting client A's global ip address 1.1.1.1 when it hits a port on the NAT that client A has sent a packet out of to client B's NAT (basically any of them at this point) it will forward the packet on to client A. and Client A would be able then respond using that connection from then on out. Now the problem with this is negotiating who goes first and then when the second client should start, so instead they both just start at the exact beginning of a minute and quite likely the first attempt will fail to yield a connection but if they both then immediately repeat the process then there should be 1 or likely even many successful connections, each client could then just discard all but the first connection that succeeded.