ICMP Query

marcusaureliusbrutus

Hi,

I have gone through several documents regarding allowing ICMP through an ASA firewall and basically have an intermediate understanding how it works. However, i have two firewalls, acting as active/active context mode which behaves quite unusually whenever i do traceroute from an application from an XP box.

Observation:

Through ASA1
a. ping from ASA to outside successful
b. traceroute through ASA successful but firewall appears as * symbol in the hop trace.

Through ASA2

a. ping from ASA to outside successful
b. traceroute through ASA successful but firewall appears to be invisible since it doesn't at all appear in the traceroute results.(checked that traffic is going through confirmed via xlate in ASA)


DATA

Configuration on both ASAs are alike for the ff:

icmp permit statesments
inbound access-lists statements


Thanks in advance.

Ahriakin

Is the application using UDP or plain ICMP traceroute (what happens if you test using Windows own traceroute tool (plain ICMP)).

Regardless that is pretty odd, the ASA should always appear as a time out hop.

_maurice

It is my understanding that the ASA will NOT decrement the TTL (Time To Live) of the packet as it traverses the firewall. This is true for both transparent mode (for obvious reasons operating at layer 2) and in non-transparent mode (routed mode). For the ASA to decrement the TTL, it must be configured via policy map/class map.

In your description, ASA2 sounds like it is operating correctly. The problem you blame ASA1 for might be happening because of the upstream router. Maybe it is rate limiting icmp unreachables. Do you control the upstream router?

Don't forget to inspect 'icmp error'. Your traceroute original destination is not the same IP address as the source of each ICMP time-exceeded ICMP packets. If this isn't applied, you will have to allow ICMP time-exceeded messages on an interface.

Ahriakin, let me know if I missed anything. Recently passed SNAF and SNAA )

Ahriakin

I'd forgotten about the TTL policy, good catch. The fact the trace is succesful would indicate he is inspecting error (unless it is blanket allowed in the ACLs), I don't think it's a factor but ya never know.

_maurice

Yup, agreed. So, the * * * in the traceroute is most likely the upstream device. Nothin like troubleshooting the wrong device... hope your paid hourly )