V7 ICMP issue

[aramsay]

All,

I have a rather stange ICMP issue since upgrading to v7.

The following happens when trying to do a ping from a machine (either in DMZ or Inside int's) to a machine past the outside interface

C:\>ping

http://www.bbc.co.uk

Pinging

http://www.bbc.net.uk

[212.58.224.124] with 32 bytes of data:

Reply from 212.58.224.124: bytes=32 time=7ms TTL=249
Reply from 212.58.224.124: bytes=32 time=6ms TTL=249
Reply from 212.58.224.124: bytes=32 time=7ms TTL=249
Reply from 212.58.224.124: bytes=32 time=6ms TTL=249

Ping statistics for 212.58.224.124:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 7ms, Average = 6ms

All works OK!

Now the problem is with the tracert from windows machines, the following happens:

C:\>tracert

http://www.bbc.co.uk

Tracing route to

http://www.bbc.net.uk

[212.58.224.124]
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 7 ms 7 ms 7 ms

http://www24.thdo.bbc.co.uk

[212.58.224.124]

Trace complete.

All the intermediate hops time out, this didn't happen on 6.2, but since upgrading to 7, we get this. Pings to the intermediate hops work fine, or doing a tracert to a hop along the route shows only the last with responses.

Interestingly, doing an icmp ping from a Solaris box, we do get the correct results as follows:

winston-smith # traceroute -I

http://www.bbc.co.uk

traceroute: Warning: Multiple interfaces found; using 192.168.2.18 @ dmfe0
traceroute to

http://www.bbc.net.uk

(212.58.224.124), 30 hops max, 40 byte packets
1 195.188.x.x (195.188.x.x) 1.394 ms 0.514 ms 0.473 ms
2 host-80-193-x-x.static.telewest.net (80.193.x.x) 1.549 ms 1.113 ms 1.076 ms
3 172.18.x.x (172.18.x.x) 3.807 ms 1.654 ms 1.610 ms
4 194.117.x.x (194.117.x.x) 7.418 ms 6.653 ms 6.504 ms
5 194.117.x.x (194.117.x.x) 7.252 ms 7.369 ms 7.039 ms
6 212.58.x.x (212.58.x.x) 7.403 ms 7.228 ms 6.775 ms
7

http://www24.thdo.bbc.co.uk

(212.58.224.124) 7.336 ms 7.206 ms 7.943 ms


If anyone's got any ideas, I'd appreciate the assistance.

Alan

 

[jjoh850]

Alan,

Windows uses ICMP echo (ping) for trace route and Unix uses UDP (which creates stateful entries in the PIX). Try allowing ICMP echo reply on your Internet ACL.

Joe

 

[aramsay]

jjoh850,

You'll notice that the UNIX traceroute uses the -I flag, which according to the man page " -I Use ICMP (ICMP6) ECHO instead of UDP datagrams". The firewall rules include the statements:

icmp permit any Outside
icmp permit any inside
icmp permit any DMZ

and

access-list Outside_access_in extended permit icmp any any
access-list inside_access_out extended permit icmp any any
access-list DMZ_access_out extended permit icmp any any

Also, if ICMP was being blocked by the firewall, ping and the final tracert destination wouldn't work too.

Alan

 

[PGRAYSON]

Any luck on this?

I've got the exact same problem. Traceroute worked fine on Windows before we upgraded the PIX to version 7.0.2, but fails now, as we'd allowed inbound ICMP Unreachable and ICMP Time Exceeded traffic.

Traceroute from UNIX systems still works, no matter if it's configured to use the UDP or ICMP method - the latter supposedly the same as that used by Microsoft.

There's nothing in our logs to show traffic being blocked inbound or outbound, either.

 

[PGRAYSON]

I've fixed it.

You have to enable inspection of both ICMP and ICMP error in your policy.

 

[aramsay]

Thanks I'll try that this weekend; we're doing some network upgrades at the moment, which means my RAS server is currently down, so can't VPN to test.

 

[aramsay]

Your quite right, adding :

policy-map global_policy
class inspection_default
inspect icmp error

to my config works a treat; out of interest, how did you discover that this was required?

 

[PGRAYSON]

It's buried in the version 7 documentation.