UDP Hole Punching impossible with non-well-behaved NATs?

Question

Normally a NAT will keep the public end point of a local end point the same for all packets that are coming from it, thus making UDP hole punching easily possible. However, some NATs will map the local end point to a different public one for each different host a packet is sent to, thus making UDP hole punching not possible.

The only way to do traditional UDP punching would be to guess the remote end point. However, since there are more than 65,000 ports, this method is not very reliable. So I've read that applications like Skype - which well-knowingly are able to communicate through pretty much any type of NAT - use a relay for that. Here are my questions:

A relay is simply a socket that transfers incoming data from one socket to another socket, right? Are there any other ways of doing UDP hole punching through naughty NATs without either taking wild guesses or using a relay (which then isn't really "hole punching" anymore)?

Answer 1

The term non-well-behaved-NATs is incorrect - any NAT device that uses PAT (port address translation) to aggregate multiple private addresses to a single public address will re-map source ports. This is what "Port Address" refers to in PAT.

It would be impossible for two internal devices to use the same source address to the same destination, and expect the source port to remain the same after NATting, and it doesn't benefit the security posture to attempt to keep the source port consistent when targetting multiple destinations. So this is generally not an aim that firewalls have in their design.

This doesn't help here of course, where you want to know the source port of a connection, without actually receiving any packets from that source. A relay is the obvious option where the endpoints communicate via a third party (yes a relay just transfers packets between sockets as you suggest - the implementation is probably far more complex within skype servers, but in principle it is the same).

It is difficult to see how you could do this any other way, as the endpoints are not aware of the translations that happen in-flight, so they couldn't even communicate what their source port is via a side channel of some kind (like only registering the port with a central server but communicating directly).