Traceroute and Access list problem

[DarylPienta]

I am having trouble allowing traceroute to work past my ACL

Here is the ACL that is causing the problem

ip access-list extended TDS_in

permit tcp host 192.168.1.13 any eq smtp

deny tcp any any eq smtp

permit icmp any any

permit ip 192.168.0.0 0.0.255.255 any

I want to be able to traceroute anywhere for now and I would like to eventually tighten icmp / traceroute capabilites

What am I missing in my ACL. it is applied in bound on our FastE port. and when I remove the ACL traceroute works, when I apply it doesn't work

[Ryan_Grant]

Can you ping past this interface?

[DarylPienta]

yes pings work fine

maybe I should add that I using traceroute from another cisco router that is connected via framerelay. I am not using a Windows cmd line tracert. However my partner was able to use a Windows cmd line tracert from the source in question and have success

Why won't it work from the cisco router ?

here is the output I get from using traceroute from router A

Tracing the route to 10.10.7.1

1 10.10.272.5 12 msec 12 msec 20 msec (this is our framerelay)

2 *

192.168.1.254 !A * (this is the Fast E port with the ACL applied in bound)

[Richard Burts]

tracert works from a Windows machine but traceroute does not work from a Cisco router because the implementations are significantly different. Cisco follows the lead of early network implementations and uses UDP packets for traceroute. Since your access list does not have a permit for UDP the Cisco traceroute does not work. The Windows tracert uses ICMP packets for it functionality. Since your access list does permit ICMP the Windows version of tracert does work while the Cisco does not.

If you want the Cisco traceroute to work your access list would need to have a permit for UDP from high number ports.

HTH

Rick

[DarylPienta]

I figured it was something of this nature.

Could someone provide me with a example of how I would successfully add this to my ACL list mentioned above.

thanks

[Richard Burts]

You can add to your named extended access list this:

permit udp any any gt 1023

you could make it slightly more restrictive if you want by substituting source or destination addresses for the any parameters.

You could also make it more restrictive by specifying a range of UDP port numbers if you are sure that traceroute will be from Cisco and will always use the default port numbers:

permit udp any any range 33434 33499

HTH

Rick

[DarylPienta]

thanks for all the info !!!

not sure why but I only needed to apply this to my cisco 2600 router, all other routers don't seem to need the extra line in the ACL's. I will assume its a IOS version thing

[Richard Burts]

I do not believe that it is an IOS version thing. This behavior has been consistent in IOS for a very long time. I am not sure why other routers do not need this line without knowing more about your network. It could be a question of what interfaces get the access list and the direction of the access list. It could be a question of where you are attempting to trace to. For example in the access list that you are using you would be able to trace successfully to any destination in 192.168.0.0 but not to any other destination because the general permit in the access list is permit ip 192.168.0.0 0.0.255.255 any. If other routers were to have something like permit ip any any then traceroute would easily work.

HTH

Rick