(HELP!) tracert problems

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



Hi,

I have a problem with tracert displaying differing results depending
on the network it is running it from. The problem is as follows:

We have deployed an RDP system to a client (over the web via L2TP/
IPSec) which seems to drop the connection every so often. We have no
problems from our network and the connection at the client site is
part of a corporate net connection, which has had no issues regarding
connectivity. The length of time between the connection drop seems to
differ, as does the time it takes to reconnect.

I have a firewall in place in front of the server serving the RDP
solution (Cisco ASA model) which has echo requests enabled to it. If I
tracert to it from one network I get a response similar to the
following:

1 <1 ms <1 ms <1 ms 192.x.x.x
2 1 ms <1 ms <1 ms 213.x.x.x
3 26 ms 26 ms 25 ms 85.x.x.x
4 26 ms 26 ms 26 ms 85.x.x.x
5 32 ms 32 ms 35 ms 195..x.x.x
6 34 ms 35 ms 35 ms 83.x.x.x
7 65 ms 50 ms 45 ms 83.x.x.x

Hop 7 in the above trace is the final IP address which resolves
correctly. If a tracert is performed on the client's site, we get a
response as follows which is exactly the same each time:

1 <1 ms 2 ms <1 ms 194.x.x.x
2 <1 ms <1 ms <1 ms 192.x.x.x
3 1 ms 1 ms 1 ms 10.x.x.x
4 1 ms 1 ms 1 ms 172.x.x.x
5 1 ms 1 ms <1 ms 172.x.x.x
6 1 ms 1 ms 1 ms 81.x.x.x
7 2 ms 2 ms 2 ms 81.x.x.x
8 3 ms 2 ms 2 ms 81.x.x.x
9 2 ms 2 ms 2 ms 81.x.x.x
10 5 ms 3 ms 3 ms 81.x.x.x
11 3 ms 2 ms 2 ms 172.x.x.x
12 3 ms 3 ms 2 ms 83.x.x.x
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 14 ms 13 ms 14 ms 83.x.x.x

Both Hop 12 and hop 25 are the final IP address, but I can't see any
reason why there are 12 timed out hops in between.

We then took the step of disabling all echo requests on the firewall
and trying the tracert again from both sites. The one from my
(working) site behaves as I would expect, in that it stops at hop 6
and any further hops timeout.

However, a further tracert from the failing site times out after hop
12, suggesting it has received a response from the final IP address.

The 2 things which are puzzling me are 1) why is it getting a response
from a firewall which has had all echo requests disabled on it and 2)
why is the response time in hop 12 of the failing site so quick, when
it has to travel the internet (supposedly) before it receives a
response. The minimum amount of time I've seen from our (working)
network for the last hop is around 30ms, which is way above the 3 ms
it took at the failing site.


Any suggestions on this one would be most welcome.


Thanks.
.



Relevant Pages

  • Re: (HELP!) tracert problems
    ... I have a problem with tracert displaying differing results depending ... on the network it is running it from. ... Both Hop 12 and hop 25 are the final IP address, ... For tracerts to work for the response to come back through a PIX or ASA, it has to be explitly allowed. ...
    (microsoft.public.windows.server.networking)
  • Re: traceroute
    ... Characters such as a.b.d.c representing a 'hop' on the ... First hop is on the internal network. ... Implementations of trace have a default timeout value (after which it ... and the trace command timed out on the response. ...
    (uk.business.agriculture)
  • Re: Cisco CTR
    ... >> addresses, hop data, peer information and so on. ... easy mistake to make seeing as you have no idea what our network looks ... > vulnerabilities we actually think are vulnerabilities). ... Martin Roesch - Founder/CTO, Sourcefire Inc. - 290-1616 ...
    (Focus-IDS)
  • Re: Can access secure site from dial-up but not from LAN network
    ... I ran the tracert to their site and it did successfully ... leave my network, but failed on the 15th hop on an address that looks to be ... > website or IP address which probably is unlikely. ... > of hopping through routers to them and would be worth a try. ...
    (microsoft.public.security)
  • Re: Lockout a country.
    ... only the last hop or three is relevant. ... It's easier to block their network and just not ... No I don't know if that refers to 2.2.5 to 2.2.15 (I don't know of any ... current distro using a kernel that old - the "current" 2.2.x kernel is ...
    (alt.computer.security)