uPnP

[Z-Man]

The port gets mangled by NAT on both sides. How do you control that?

[Luke-Jr]

It's a non-issue. UDP lacks the need for any one end initiating the connection. Each dummy packet (sent in both directions) will open that end's NAT up to the other end's connection.

[Z-Man]

Eh? If A is behind NATA and B is behind NATB, A sends a packet from port 1 to B's port 2, then NATA will mangle the source port to, say, 1001 and of course the source IP as well. NATB will see ap packet from NATA, port 1001, desitined for port 2. Port 2 hasn't been used, so it can't possibly be open and the packet is dropped. B doesn't see it, A doesn't know which port it was mangled to, B neither. A possible packet sent from B to A gets the same fate. A and B are, even through an existing outside channel, completely unable to communicate the ports that may have been opened on the NATs. It can work only if one of the NATs doesn't rewrite ports unless it has to.

The only way that can possibly work is if A and B send a packet from port 1 to a known good server C, port 3, that both A and B have a connection with. C records the ports the packets originated from and tells them to A and B. Now, possibly, A can send a packet to the port NATB has opened and can hope it gets through to B. Hope is the keyword here, because neither the source port nor the source IP match anything NATB could expect for a normal outgoing connection; it would expect the packet to come from C, port 3. Instead, it gets a packet from A, port 1001. Some implementations will accept this, others won't.

Whatever method you choose, there is no way to *reliably* establish a direct connection between two hosts that are both behind a NAT thing.