Traceroute problems

[sanchez.l]

I have a 1841 with IOS c1841-ipbase-mz.123-8.T7.bin,

when I do a trace to an address that is not in the table it reply in the first hub

MS1RTR01#trace

Protocol [ip]:

Target IP address: 198.133.219.25

Source address:

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]:

Minimum Time to Live [1]:

Maximum Time to Live [30]:

Port Number [33434]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Type escape sequence to abort.

Tracing the route to 198.133.219.25

1 198.133.219.25 16 msec 4 msec 0 msec

MS1RTR01#trace 198.133.219.25

Type escape sequence to abort.

Tracing the route to 198.133.219.25

1 198.133.219.25 0 msec 0 msec 4 msec

This router is not even connected straight to the Internet is going to a "firewall" (watchguard), does anybody have this problem before?

Regards

Luis

[Richard Burts]

I have seen this situation multiple times at a customer site. We investigated and found that the firewall was generating the response to these trace messages. I suspect that if you check you will find that your firewall is not allowing the trace to go through and is generating the responses.

HTH

Rick

[sanchez.l]

The weird thing is that when you trace from a PC that has the router as DG it goes to the internet, however the PC shows the firewall as first hub and not the router (the router must be sending ICMP redirects)

H:\>tracert www.cisco.com -d

Tracing route to www.cisco.com [198.133.219.25]

over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 10.10.0.20

2 9 ms 9 ms 9 ms 207.61.11.225

3 * * * Request timed out.

4 9 ms 9 ms 9 ms 64.230.206.77

5 9 ms 9 ms 9 ms 64.230.242.194

6 24 ms 24 ms 24 ms 206.108.103.118

7 24 ms 25 ms 84 ms 206.108.103.122

8 58 ms 49 ms 44 ms 160.81.109.193

9 48 ms 24 ms 26 ms 144.232.26.65

10 24 ms 24 ms 27 ms 144.232.26.101

11 71 ms 71 ms 71 ms 144.232.20.161

12 71 ms 71 ms 71 ms 144.232.3.157

13 71 ms 73 ms 72 ms 144.232.3.138

14 78 ms 78 ms 78 ms 144.228.44.14

15 83 ms 83 ms 109 ms 128.107.239.5

16 132 ms 82 ms 86 ms 128.107.224.65

^C

[Kevin Dorrell]

There is something different about traceroute of a PC : I think it tries to connect to TCP/445 or something like that, whereas the router goes for a UDP high port. The firewall may handle these two situations rather differently.

Kevin Dorrell

Luxembourg

[Kevin Dorrell]

That is interesting, what Rick suggests. I suppose that would make the "firewall" into a "proxy" rather than a "firewall", at least as far as the UDP echo is concerned. Thanks for sharing that experience Rick.

It would be interesting to find out what would happen if there was no route to 198.133.219.25 beyond the firewall. Would the firewall still respond by proxy? The response times seem to suggest that the firewall is indeed responding before it even has a chance to check 198.133.219.25 for real.

Kevin Dorrell

Luxembourg

[sanchez.l]

I opened the traceroute port in the Watchguard, it is called traceroute and you cannot see the port number and now it is working

Thanks

[Richard Burts]

It is good to know that my suggestion that it was a firewall issue was the right solution.

I think Kevin was going in the right direction when he commented that there is a difference between traceroute on a router vs tracert on a PC. The traceroute on a router does generate UDP packets to various high number ports while the tracert of a PC uses ICMP. My guess is that the tracerotue port on the Watchguard is looking for the ICMP messages.

I am glad that you have resolved your problem.

HTH

Rick