TCP Traceroute in windows

Recently at the office, we ran into a typical problem of TCP ports on a few specific servers blocked by firewall or router ACL. Being the network curious guy that I am, it got me looking back into the use of programs that could traceroute to tcp ports. The problem though is every system available for testing is Windows based. My search for a good solution is still in progress, but I have gone in 5 directions so far.

1) Hping2 for windows. Tried the post xp sp2 version of this on both 2003 server and win 7 enterprise. For 2003 server it worked partially, but I couldn't get any options to run and it didn't seem to do anything other than resolving hostnames. For windows 7, it crashes regardless of any compatibility settings or rights. If there is some trick to getting it working, I didn't find it in brief googling for it. Perhaps there is some missing dependency or extra effort required to get this working, I only used the precompiled version that is in the windows version download.

2) .NET sockets. You can set TTL value on a socket object, but apparently the OS will ignore this when setting up a TCP connection.

From MSDN

"Setting this property on a Transmission Control Protocol (TCP) socket is ignored by the TCP/IP stack if a successful connection has been established using the socket."

From netmon it looks like the 3 way handshake goes by system default TTL and skips whatever you requested.

3) Registry hacking. In HKLM\System\CurrentControlSet\Services\Tcpip\Parameters, you can create a DWORD value called DefaultTTL which can change your OS default TTL. The obvious drawback would be that this is going to break your network connections to other systems while you try the traceroute. And if you are remotely connected to a machine you want to run traceroute from, then its not a viable option as you would probably get kicked off the system. Other cavaets are that in windows 2003 server, the setting does not appear to take effect immediately. In Windows 7 however, it does. So if you are at the console of a Win7 machine (maybe also 2008 srv/vista...didn't try that. 2003 server does not appear to update immediately.), you could have a script to update the reg value, make a connection attempt with any standard method of opening an arbitrary TCP connection that can show the IP that the "TTL expired in transit" result is coming from and incrementally up the DefaultTTL registry until you get this error. But overall, this doesn't seem like a practical approach.

4) Success at last, SCAPY for windows. Installation is pretty simple following the guide (http://trac.secdev.org/scapy/wiki/WindowsInstallationGuide).....BUT to get it working you need 7 different components installed on your system to run it. So if you are running from your workstation or a common source where you can have this set up in advance of the problem, it works great. If the network block you are looking for doesn't effect the machine you have it installed on, then it is much less practical and you have to rely on your firewall/network guys to find the cause of the block.

5) Nemesis. I tried to get a bit simpler than scapy with this one. Initially it failed on dll problems. This was fixed with a major downgrade of winpcap to ver 3.0 (http://www.security-forums.com/viewtopic.php?t=29485). Still on Win7, running the program fails when cmd is under admin privileges with unable to create raw socket error. Checking back on the project site shows nemesis hasn't been updated since 2004, so no surprise there.

So in the future, if I have enough time and dig around with programming some more, maybe there will be some simple script solution out there, but I suspect most avenues have been blocked off by restrictions on raw sockets.