Showing results for 
Search instead for 
Did you mean: 

ASA 5500 and ICMP Unreachable


Is it really the case that the ASA will not generate ICMP Host Unreachable messages for subnets connected to any of its interfaces (in breach of RFC1812) as claimed here: ?

I'm investigating a situation where an organisation uses ASAs to control traffic between different vlans in their internal production systems as well as Internet traffic.  They are having problems with internal load balancing because the ASAs do not (as currently configured) generate Host Unreachable packets.  Can this be changed in the configuration or not?  I have to say, if it can't then I'd urge them to find something else to route between their internal subnets.



Actually, reading that post I linked to, I see that guy may not have been describing the same problem.  What we need is for the ASA to generate Host Unreachable messages when ip packets are sent to to an unreachable host on one of the connected subnets.  Can we configure this?


The way ASA behaves is, it creates reverse flow for a connection (i.e flow to allow return traffic on the conn) ONLY for TCP/UDP/ICMP/PIM protocols. The reverse flow also allows ICMP errors generated by intermediate devices for that connection to pass through the ASA to reach source, this is possible only with the Inspect ICMP error configured as shown here :

ASA(config)# policy-map global_policy

ASA(config-pmap)#  class inspection_default

ASA(config-pmap-c)# inspect icmp error

We have a doc-bug opened for the same :

ICMP error messages are generated by destination or intermediate hops to  report an error to the source of traffic. Documentation related to how  ASA handles these ICMP error messages is missing.

For protocols  which do not have bi-directional traffic, ASA creates only one direction  of flow, i.e. creates forward flow in Ingress direction, but no reverse  flow on Egress direction.

As of now, these flows are created for TCP/UDP/ICMP/PIM protocols only as of now.

In  general when a ICMP error packet hits the ASA, reporting error for a  connection, we don't create new flow for that ICMP. Instead we look into  the existing flow DB to find out the connection for which ICMP error is  reported. If a reverse flow exists for the connection in the ICMP  error, it is passed, else dropped with following syslog:

%ASA-4-313005:  No matching connection for ICMP error message: icmp src  outside: dst inside: (type 3, code 4) on outside  interface.  Original IP payload:

Hope that helps.

Hi.  Thanks for getting back, but it doesn't address my specific question.  I'm not talking about the ASA allowing ICMP traffic from other devices to pass through; I'm asking about the ASA generating ICMP messages itself.  When the ASA is the final hop router for traffic to a particular subnet (that is, when there is no other router between the ASA and the subnet), if it receives traffic for an ip address on that subnet and there is no host with that address, then the ASA should be generating ICMP Host Unreachable messages.  If it does not do this, connection attempts to those addresses will hang until the connection times out.  Now, RFC1812 states that all routers MUST do this.  In the real world, most people suppress these messages on untrusted (e.g. Internet-facing) interfaces.  However, the ASA seems to supporess Host Unreachable messages on all interfaces by default.  I want to know if it is possible to enable Host Unreachable message generation on trusted interfaces.  It is very important for our High Availability architecture to know whether or not the ASA can be configured to generate these messages; if it cannot, we have to redesign our networks. The ASA documentation does not seem to cover this, nor does the extra information in your doc-bug.

In a sense, I suppose I am reporting another omission in the documentation.  If the ASA will never generate these messages, this should be documented, not least since it is a violation of RFCs. If they can be made to generate them, that is important to know.  Either way, the documentation is currently inadequate.

Hello Bruce,

My apologies as i misunderstood your question. I know there were issues with PMTUD through the firewall but never heard of any issues about the Firewall not generating Type 3 Code 4 Packets. I for sure know that the Firewall generates the Type 3 code 4 packets. It originates with the Firewall's IP address closest to the source.

     10: 13:48:30.618147 > icmp: unreachable - need to frag (mtu 1434)

     11: 13:48:32.618742 > icmp: unreachable - need to frag (mtu 1434)

I have seen cases where the packets were being dropped by the ACL associated with the Interface so i would recommend a configuration as shown:

   access-list outside permit icmp host  any Unreachable 4
   access-group in interface 

Can you let me know which code version you are running and also what tests you did and if you took a span port capture of the firewall interface and checked if the Type 3 Code 4 packets are being generated or not please ? Also if you can set the syslogs to debugging while doing this to make sure we can determine the root cause.


Hi everyone,

@pgoutham: you´re actually defining the CODE of the ICMP Type 3 as well, as shown in the command?!? Which OS version have u got on your FW?

@Bruce: we allow all UNREACHABLE (Type 3 ICMPs), and I guess this would also solve your problem.

access-list outside_access_in extended permit icmp any any unreachable

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: