traceroute from behind a pix not working properly
i have 8 clients that have the same configuration and the same problem
we have a pix 515e with the OS 7.0.1
i can ping out of the network from the machines on PAT and NAT
but
if i do a traceroute either from PAT or NAT
i get the same problem:
only the last hop (the one that i am tracing) answers
ie:
Tracing route to www.yahoo.akadns.net [68.142.226.41]
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 124 ms 123 ms 125 ms p10.www.re2.yahoo.com [68.142.226.41]
i even tried to add, on top of the implicit outbound rule, two rules to permit icmp in and out. but no luck
any ideas?
thanks a lot
TS
we have a pix 515e with the OS 7.0.1
i can ping out of the network from the machines on PAT and NAT
but
if i do a traceroute either from PAT or NAT
i get the same problem:
only the last hop (the one that i am tracing) answers
ie:
Tracing route to www.yahoo.akadns.net [68.142.226.41]
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 124 ms 123 ms 125 ms p10.www.re2.yahoo.com [68.142.226.41]
i even tried to add, on top of the implicit outbound rule, two rules to permit icmp in and out. but no luck
any ideas?
thanks a lot
TS
I have seen this when trying to do a traceroute from a private network to a public network.
What result are you looking for? Is knowing that there is a path to yahoo not enough?
What result are you looking for? Is knowing that there is a path to yahoo not enough?
ASKER
sh icmp does not seem to work or even exist
i have those lines in the configuation:
icmp permit any outside
icmp permit any echo outside
icmp permit any echo-reply outside
icmp permit any inside
access-list outside_access_in line 16 extended permit icmp any any echo-reply (hitcnt=1)
access-list outside_access_in line 17 extended permit icmp any any time-exceeded (hitcnt=65)
access-list outside_access_in line 18 extended permit icmp any any unreachable (
hitcnt=4)
access-list outside_access_in line 19 extended permit icmp any any (hitcnt=77)
i have those lines in the configuation:
icmp permit any outside
icmp permit any echo outside
icmp permit any echo-reply outside
icmp permit any inside
access-list outside_access_in line 16 extended permit icmp any any echo-reply (hitcnt=1)
access-list outside_access_in line 17 extended permit icmp any any time-exceeded (hitcnt=65)
access-list outside_access_in line 18 extended permit icmp any any unreachable (
hitcnt=4)
access-list outside_access_in line 19 extended permit icmp any any (hitcnt=77)
ASKER
if knowing that a path to yahoo exists was enough, I would use ping
the reason i need tracert to work is because i need to know what the path is ;)
Try adding:
icmp permit any echo-reply inside
Your access lists look fine.
icmp permit any echo-reply inside
Your access lists look fine.
ASKER
didn't help matt
is there a perimeter router between the pix and the internet?
ASKER
yes
any chance there's an access list there blocking icmp traffic?
from http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00800e9312.shtml
it looks like you need to add:
icmp permit any unreachable outside
icmp permit any time-exceeded outside
if you would, please try to traceroute from the pix before and after adding the icmp permit commands, by ip address and post the results
it looks like you need to add:
icmp permit any unreachable outside
icmp permit any time-exceeded outside
if you would, please try to traceroute from the pix before and after adding the icmp permit commands, by ip address and post the results
ASKER
nope nothing is blocking in the router
remember that i can ping outside and if i do a trace, i get all timeouts expet for the lst hop which does answer
remember that i can ping outside and if i do a trace, i get all timeouts expet for the lst hop which does answer
ASKER
pix does not support the traceroute or tracert command
those two commands did not help either
those two commands did not help either
That's strange...
I can traceroute through my 515 to the internet with only the following:
access-list inbound line 1 permit icmp any any time-exceeded (hitcnt=1520)
access-list inbound line 2 permit icmp any any echo-reply (hitcnt=30351)
access-group inbound in interface outside
icmp permit any echo-reply outside
icmp permit any echo inside
icmp permit any echo-reply inside
I can traceroute through my 515 to the internet with only the following:
access-list inbound line 1 permit icmp any any time-exceeded (hitcnt=1520)
access-list inbound line 2 permit icmp any any echo-reply (hitcnt=30351)
access-group inbound in interface outside
icmp permit any echo-reply outside
icmp permit any echo inside
icmp permit any echo-reply inside
ASKER
one big news
the traceroute works from a linux box (red hat) that i have on the network
but it still doesn't work from the windows machines :-(
maybe icmp is declared wrong on this IOS?
any other ideas?
the traceroute works from a linux box (red hat) that i have on the network
but it still doesn't work from the windows machines :-(
maybe icmp is declared wrong on this IOS?
any other ideas?
i wonder if something has changed in 7.1.... I'm still running 6.3
ASKER
what IOS are you using matt?
Just to keep things in perspective....
icmp permit | deny commands on the PIX *only* affect that particular interface. You can allow/restrict how that specified interface reacts to icmp packets. It has nothing to do with allowing the icmp time-exceeded packets to come back into the pix. That is handled exclusively by the access-list which apparently is already in place and working:
>access-list outside_access_in line 17 extended permit icmp any any time-exceeded (hitcnt=65)
>because i need to know what the path is ;)
Why? You have absolutely no control over the path once it leaves your PIX outside interface anyway. You have absolutely no control over how any of those routers in that path respond to the trace packets. Many are configured to simply ignore them for security purposes.
Given the hitcount on the access-list, it is apparent that some of them have indeed responded, yet something has prevented that from being passed back to the client. Do you have fixup icmp enabled on the PIX? Given that there are now 6 iterations of bug-fixed versions of 7.0, it could be that you have encountered a bug...
icmp permit | deny commands on the PIX *only* affect that particular interface. You can allow/restrict how that specified interface reacts to icmp packets. It has nothing to do with allowing the icmp time-exceeded packets to come back into the pix. That is handled exclusively by the access-list which apparently is already in place and working:
>access-list outside_access_in line 17 extended permit icmp any any time-exceeded (hitcnt=65)
>because i need to know what the path is ;)
Why? You have absolutely no control over the path once it leaves your PIX outside interface anyway. You have absolutely no control over how any of those routers in that path respond to the trace packets. Many are configured to simply ignore them for security purposes.
Given the hitcount on the access-list, it is apparent that some of them have indeed responded, yet something has prevented that from being passed back to the client. Do you have fixup icmp enabled on the PIX? Given that there are now 6 iterations of bug-fixed versions of 7.0, it could be that you have encountered a bug...
ASKER
i just installed IOS 7.0.1.5
and it did not fix the problem :(
any other ideas?
and it did not fix the problem :(
any other ideas?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
> the traceroute works from a linux box (red hat) that i have on the network
> but it still doesn't work from the windows machines :-(
THAT is an important clue!!!!!
There are two different implementations of traceroute.
A. Send icmp echo-request
Receive icmp time-exceeded until receive icmp echo
B. Send UDP on ports in the 33000-35000 range (it's actually more restrictive than that
Receive icmp traceroute(?) until receive icmp unreachable
It is highly likely that the Linux box does one and the Windows boxes do the other.
I don't see "icmp traceroute" in your rules.
> but it still doesn't work from the windows machines :-(
THAT is an important clue!!!!!
There are two different implementations of traceroute.
A. Send icmp echo-request
Receive icmp time-exceeded until receive icmp echo
B. Send UDP on ports in the 33000-35000 range (it's actually more restrictive than that
Receive icmp traceroute(?) until receive icmp unreachable
It is highly likely that the Linux box does one and the Windows boxes do the other.
I don't see "icmp traceroute" in your rules.
FYI - How do Unix and Windows traceroute differ?
from: http://www.tech-faq.com/unix-windows-traceroute.shtml
The Unix/Linux `traceroute` command and the Microsoft Windows `tracert` commands both accomplish the task of tracing network paths, but they do it in slightly different ways.
Both of these tools for tracing network routes send out a packet wth TTL (Time To Live) set to 1 and report it's destnation. Then, they send out a packet with TTL=2 and report it's destination. They continue until the packets reach their final destination or the TTL limit is exceeded.
The difference is that Unix/Linux `traceroute` uses UDP (User Datagram Protocol) packets to a random high port number, while Microsoft Windows uses ICMP (Internet Control Message Protocol) packets.
This difference is critical when trying to understand why traceroute sometimes fails. The firewall rulesets and the router Access Control Lists (ACLs) between you and the destination must be examined to determine if they allow UDP high ports and/or ICMP.
In addition, the command line options for Microsoft Windows `tracert` differ from the command line options for Unix/Linux `traceroute`. However, the command line options for Unix/Linux `traceroute` also differ between Unix versions. Read the manual page for your Unix/Linux system to explore the troubleshooting options available to you.
what he said :)
from: http://www.tech-faq.com/unix-windows-traceroute.shtml
The Unix/Linux `traceroute` command and the Microsoft Windows `tracert` commands both accomplish the task of tracing network paths, but they do it in slightly different ways.
Both of these tools for tracing network routes send out a packet wth TTL (Time To Live) set to 1 and report it's destnation. Then, they send out a packet with TTL=2 and report it's destination. They continue until the packets reach their final destination or the TTL limit is exceeded.
The difference is that Unix/Linux `traceroute` uses UDP (User Datagram Protocol) packets to a random high port number, while Microsoft Windows uses ICMP (Internet Control Message Protocol) packets.
This difference is critical when trying to understand why traceroute sometimes fails. The firewall rulesets and the router Access Control Lists (ACLs) between you and the destination must be examined to determine if they allow UDP high ports and/or ICMP.
In addition, the command line options for Microsoft Windows `tracert` differ from the command line options for Unix/Linux `traceroute`. However, the command line options for Unix/Linux `traceroute` also differ between Unix versions. Read the manual page for your Unix/Linux system to explore the troubleshooting options available to you.
what he said :)
ASKER
penngwyn, what do you mean with:
" I don't see "icmp traceroute" in your rules. "
" I don't see "icmp traceroute" in your rules. "
ASKER
it's really weird, nothing seems to help
nobody has any other ideas?
nobody has any other ideas?
ASKER
i actually opened a case with cisco and the asnwer is:
just enable
inspect icmp
and
inspect icmp eroor
that's it
this is a feature of the IOS 7.*
inspect comes disabled by default on this IOS for icmp and it is necesary for traceroute to go through the pix properly (don't ask me why)
i am giving the points to lrmoore who had suggested to try to work on this with the inspection engine
thanks to all and cheers
TS
just enable
inspect icmp
and
inspect icmp eroor
that's it
this is a feature of the IOS 7.*
inspect comes disabled by default on this IOS for icmp and it is necesary for traceroute to go through the pix properly (don't ask me why)
i am giving the points to lrmoore who had suggested to try to work on this with the inspection engine
thanks to all and cheers
TS
cheers, and thanks for letting us know what worked.
sh icmp
sh access-list (acl on the outside interface)