Re: (HELP!) tracert problems

"bernie sprouster" <> wrote in message
news:883033cb-ea66-4447-894e-...
> 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.


For tracerts to work for the response to come back through a PIX or ASA, it
has to be explitly allowed.

For Pix 5 or newer:
access-group 101 in interface outside
access-list 101 permit icmp any host 209.165.200.246 unreachable
access-list 101 permit icmp any host 209.165.200.246 time-exceeded
access-list 101 permit icmp any host 209.165.200.246 echo-reply

More info:
http://www.cisco.com/en/US/products/....shtml#topic1a

Also, if you are trying to tracert from an external source through a Pix to
an internal resource, such as web server, a Pix does not support the
traceroute command. When a traceroute is issued from the outside, the PIX
does not display its own interface IP address nor does it display the IP
addresses of the inside networks. The destination address is displayed
multiple times for each internal hop.

In PIX version 6.3 and later, this behavior can be undone if the fixup
protocol icmp error command is issued. When this feature is enabled, the PIX
creates xlates for intermediate hops that send Internet Control Message
Protocol (ICMP) error messages, based on the static NAT configuration. The
PIX overwrites the packet with the translated IP addresses.

More info:
http://www.cisco.com/en/US/products/...8a.shtml#trace

This applies to Pix and the ASA.


--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum to benefit from collaboration
among responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCSE, MCSA 2003 & 2000, MCSA Messaging
Microsoft Certified Trainer

http://twitter.com/acefekay

For urgent issues, you may want to contact Microsoft PSS directly. Please
check http://support.microsoft.com for regional support phone numbers.

"bernie sprouster" <> wrote in message news:8a3d6c6d-7441-4033-beeb-...
> Thanks for the info. I'm still unclear as to why I would see different
> results from one site than another, specifically why there would be so
> many timeouts before eventually receiving a response. I'm also a
> little unsure as to why the response is 3ms. That to me would signify
> a cached response.


Not sure. The only thing that sticks out from what I found, is the "The destination address is displayed
multiple times for each internal hop," which I thought may apply to your situation.

Sorry I couldn't help any further.

Ace