The official Cisco CCNP Security FIREWALL training course (as well as other documentation) recommends enabling the inspection of the Internet Control Message Protocol (ICMP), even though it’s disabled by default. The image below displays the recommended practice as configured in ASDM, but the curious student might wonder what the unchecked “ICMP Error” box is. That’s what I’ll focus on in this post.
The ICMP existed for more than 30 years, having largely been specified in RFC792. Most network engineers are familiar with its diagnostic capabilities via ping and the assorted “unreachable” messages. What’s most likely not as well recognized is that the ICMP message often contains the first 28 bytes of the packet that caused the error. Since the IP header itself is frequently limited to 20 bytes, this ensures that the source and destination addresses will be seen since these are at the end of the header. An excellent graphic of the ICMP error message can be seen below.
With the embedding of IP addresses in this return packet in mind, a network admin is presented with an interesting diagnostic challenge. If the “packet that caused the error” (as often stated in the return message) was translated by a Network Address Translation (NAT) device between its point of origin and the point of error, then the reported source address needs to correlate to the current NAT device translation table — a bothersome task at best.
Cisco Systems provided NAT support for such a scenario in the PIX Operating System version 6.3 with the fixup protocol ICMP error command. As the Configuration Guide for this operating system suggests, the recognition of NAT-relevant IP addresses in diagnostic return messages was implemented before the general inspection capability for ICMP packets introduced in ASA/PIX OS7.0. In addition, the syntax changed with this release to “deprecate” (Cisco lingo for obsolete) the fixup command and replace it with the more general inspect.
One of the implied fringe benefits of the switchover to the inspect syntax is to use this as part of the overall Modular Policy Framework capability of OS7.0 and beyond. A network administrator could configure the ASA for the inspection of ICMP error packets to occur only for specific flows (from the out-of-band IT management network, for example). This would avoid a potentially unnecessary saturation of the NAT table.