UDP hole-punching: testability on single machine

Question

I'm writing a simple P2P application to test the feasibilty of using UDP hole-punching in a larger project.

I tried my test apps from home yesterday and they worked.

However, I am now at work and the same code no longer does the job. The sender is sending to the appropriate port on the external IP address of our router here, but the receiver isn't getting any of them.

Prior to calling UdpClient.Receive(), the receiving app sends a packet to the IP:port that it will be listening on. Again, this works on my home setup, but not here. The outcome is the same regardless of whether Windows Firewall is on or off, so that's not the issue.

Could it be that the routers are handling the situation differently?

EDIT1: Both apps run on the same machine.

Answer 1

In answer to my own question:

The routers were indeed exhibiting different behavior.

My home router is hooked up to just my laptop. I assume this is why when I send out a UDP packet from port n it also leaves the router on port n.

However, my work network consists of several computers and the router randomizes the port on its end, which means that a packet sent from port y will leave the router on port x.

I have successfully gotten my home and work machines to communicate through NAT without using port forwarding in the following way:

H - Sends packet from port a to W:b, thereby opening port a for incoming connections

W - Sends packet to H:a and switches to receive mode. It too now has an open port.

H - Receives packet from W and instead of presuming to know which port to reply to, checks the packet for its source port and uses that instead.

H - Sends packet to W:source port

W - Receives packet.

Voila.

In practice, tho, H and W would contact a server to exchange connection details, which simplifies matters because the server knows exactly which ports H and W are sending from.