UDP hole punching host-specific failure

Question

I wrote a program that sets-up peer-to-peer links. The programm, which can be found at http://basyl.co.uk/code/punch/doc/files/Readme-txt.html, is in two parts: a server that r

Answer 1

I can't quite follow all that, but it sounds like you want to use an intermediary server to discover the source UDP ports for Clients A and B so that A and B can simultaneously send UDP datagrams at each-other, thereby opening NAT rules and (eventually) allowing the traffic through.

Here's the problem: NAT can map the source port to whatever it wants. When B sends a datagram to the server, there's no guarantee that the source port seen by the server will be the same one that is used when B sends a datagram to A.

There are a lot of reasons why the NAT might change the port number, and a security conscious one will randomize just to prevent what you are trying to do. So while you may be able to make double punching (NAT to NAT) work sometimes, you cannot do so every time.

Answer 2

So in summary, the client doesn't work on a particular host when the server is on the same host. Any suggestions for reasons for this behaviour

Could it be that the server sees clientA as being on 127.0.0.1 (or maybe a non-routable LAN address?) and not its public IP-address?

If clientB tries to contact clientA using the wrong address, it's obvious why the UDP-datagram doesn't get to the intended recipient.

or for ways I could investigate this further?

Some output from tcpdump from both the server (AKA clientA) and clientB would help a lot. You might want to use -i any and maybe -s 0.

Answer 3

the client doesn't work on a particular host when the server is on the same host

In some corner cases, NATs only accept traffic from the target IP address:port used to punch the hole. Since it is not the one of the remote NAT-ed peer, they block the traffic from it. This could explain your issue.