UDP traceroute utility

I needed a traceroute tool for windows that not only used UDP, but let you set the source and destination UDP port numbers. This was to try and resolve a UDP communications problem between a client and a server in an enterprise network, where there were all sorts of NAT devices and firewalls between the machines that I didn’t have access to.

I wanted to be able to trace with a random source port, and a fixed destination port from the client to the server, and then trace back again with a fixed destination port and fixed source port back to the client. That way I should be able to ride through the firewalls on the dynamic rules they should have created and see at what point a device was blocking, or returning a unreachable.

You can get the (.NET Framework 2.0) udptrace executable here: udptrace.exe
Project source here: udptrace-src.zip

C:\data\udptrace>udptrace.exe squffy.neko-san.net:229

the output should look similar to this example trace from client to server ‘eej66.example.com’:
The last hop should indicate “destination unreachable (code 3)” (since the destination service is not running, code 3 is ‘port unreachable’) and this shows that your UDP packets get all the way to the server (or not, if they’re being blocked in that direction).

C:\data>udptrace squffy.neko-san.net:229

Tracing route to squffy.neko-san.net [188.246.204.62]
using 52 byte packets, from local port 51488, over a maximum of 20 hops:

  1     93 ms   93 ms   109 ms  10.233.0.1 (10.233.0.1)
  2     10 ms   234 ms  321 ms  78-86-20-1.zone2.bethere.co.uk (78.86.20.1)
  3     15 ms   15 ms   15 ms   195.66.226.228 (195.66.226.228) (datagram stripped)
  4     15 ms   15 ms   15 ms   85.158.41.163 (85.158.41.163) (datagram stripped)
  5     15 ms   31 ms   0 ms    213.5.88.1 (213.5.88.1) (datagram stripped)
  6     15 ms   15 ms   0 ms    213.5.88.72 (213.5.88.72)
  7     15 ms   15 ms   15 ms   squffy.neko-san.net (188.246.204.62) ICMP dest unreachable (code 3)

If this is successful, then soon after your trace is performed (should be less than 30 seconds after, so any dynamic firewall rules don’t expire) you should run a trace on the server back to the client IP address with an option set to force the source port to 229 and the destination port to the one the client machine used (which is given in the first line of the client trace. in the example above it is 51488).

The command run on the server will then look like this (replacing 10.x.x.x with the client’s IP address):

udptrace.exe -l 229 squffy.neko-san.net:51488

and you should get a similar trace, ending in “destination unreachable (code 3)” since the client has no listener on that port. This example is all what we’d expect if the communication was working fine, but if you’re having a problem you’d see unreturned packets, packets returned by ICMP from the wrong host, or packets taking a wrong route.

Check here for information on ICMP message codes: http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
Specific information on destination unreachable codes: http://en.wikipedia.org/wiki/ICMP_Destination_Unreachable
And information on UDP packet structure: http://en.wikipedia.org/wiki/User_Datagram_Protocol