# tracert not working (completely baffled!)



## rolinger (Dec 11, 2008)

Hello all, I have multiple XP computers behind my PIX firewall. I have enabled icmp through the PIX to further test this problem. All but one (SystemX) of my computers can traceroute properly. Traceroute on SystemX was working til a few weeks ago, then suddenly it started "request timed out" for every hop except the final destination. The DNS is working because initial name to IP translation is occuring before the trace begins. The fact that the traceroute goes the same amount of hops as working systems baffles me and the fact that it gets a proper response from the final destination further baffles me. To me, it tells me that traceroute IS working, that icmp is NOT blocked...but yet, its not working correctly.

SystemX does not have the local firewall enabled, I even recopied the \i386\tracert.ex_ to the system32 folder thinking the original tracert.exe somehow got corrupted. I verified all the tcp settings to be identical to my other computers (static IP with hard coded dns). And as best as I can tell there aren't any IPSec policies within "Administrative Tools -> Local Security Policy".

I have searched google all day and have only found one reference to a similar issue but it was 7 years old and was concerning Windows2000

From any working System:
C:\>tracert -d www.bankofamerica.com

Tracing route to wwwui.global.bankofamerica.com [171.159.100.100]
over a maximum of 30 hops:

1 5 ms 4 ms 5 ms 72.77.248.1
2 4 ms 4 ms 4 ms 130.81.48.210
3 12 ms 29 ms 7 ms 130.81.29.53
4 4 ms 4 ms 4 ms 130.81.19.36
5 16 ms 17 ms 17 ms 130.81.17.115
6 18 ms 19 ms 19 ms 130.81.19.29
7 18 ms 19 ms 19 ms 152.63.81.1
8 86 ms 87 ms 87 ms 152.63.54.130
9 84 ms 84 ms 84 ms 152.63.51.125
10 83 ms 84 ms 84 ms 157.130.193.250
11 89 ms 89 ms 89 ms 171.159.64.231
12 88 ms 89 ms 89 ms 171.182.95.2
13 88 ms 92 ms 89 ms 171.159.100.100

Trace complete.

From SystemX: 
c:\>tracert -d www.bankofamerica.com

Tracing route to wwwui.global.bankofamerica.com [171.159.228.100]
over a maximum of 30 hops:

1 * * *  Request timed out.
2 * * * Request timed out.
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 45 ms 44 ms 44 ms 171.159.228.100

Trace complete.


----------



## rolinger (Dec 11, 2008)

I downloaded "ftrace.exe" (an alternative 3rd party traceroute application) and it too is suffering the same problem was regular windows "tracert". It correctly translates the name, begins the trace...times out all hops except for the destination hop.


----------



## rolinger (Dec 11, 2008)

I just ran the computer in Safe Mode With Networking - and traceroute (tracert) worked just fine. So something has changed in full Windows mode that is causing this odd behavior. And its driving me mad. Ugh!


----------



## rolinger (Dec 11, 2008)

...oh...and one last thing. Basic old ping works just fine:

c:\>ping www.bankofamerica.com

Pinging wwwui.global.bankofamerica.com [171.159.100.100] with 32 bytes of data:

Reply from 171.159.100.100: bytes=32 time=89ms TTL=243
Reply from 171.159.100.100: bytes=32 time=91ms TTL=243
Reply from 171.159.100.100: bytes=32 time=88ms TTL=243
Reply from 171.159.100.100: bytes=32 time=91ms TTL=243

Ping statistics for 171.159.100.100:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 88ms, Maximum = 91ms, Average = 89ms


----------



## rolinger (Dec 11, 2008)

Wow...I finally fixed it. I found an obscure MSKB referencing something other than what my problem was but the recommended fix for that issue also fixed my issue. I don't even recall what led me to this KB, but it worked: http://support.microsoft.com/kb/299357

Specifically, the fix was reset the tcp/ip stack:
1: from cmd prompt: netsh int ip reset c:\resetlog.txt
2: reboot computer


----------



## rolinger (Dec 11, 2008)

heh...but resetting the tcp/ip stack has now caused my Cisco VPN Client to not work. Great!


----------



## rolinger (Dec 11, 2008)

crap...just occurred to me that I posted this in the wrong forum. apologies.


----------



## johnwill (Sep 26, 2002)

Reinstall the Cisco VPN client and it'll work. Resetting the TCP/IP stack removes all the LSP shims, one of which the VPN client was depending on.


----------



## rolinger (Dec 11, 2008)

I did reinstall the vpn client which got my vpn working again, however, tracert is no longer working.

1. reset tcp/ip stack, tracert worked, but caused vpn to fail
2. reinstalled vpn, and even before the required reboot after install, tracert no longer worked. After reboot, vpn was working but tracert was still failing (or doing that same behavior)


----------



## johnwill (Sep 26, 2002)

I've had problems with some versions of the Cisco client blocking other networking, even when the VPN tunnel is not active. I don't have a solution.

What I did here for one client is run the VPN in a virtual machine using VMWARE, that stopped the VPN client from stepping on the host machine's networking.


----------

