ASA 5500 and ICMP Unreachable

bruce-nap · ‎06-28-2012

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: https://supportforums.cisco.com/thread/2093028 ?

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.

bruce-nap · ‎06-29-2012

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?

pgoutham · ‎06-30-2012

Bruce,

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 :

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtn00273

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:172.16.0.2 dst inside:192.168.10.1 (type 3, code 4) on outside interface. Original IP payload:

Hope that helps.

bruce-nap · ‎07-02-2012

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.

pgoutham · ‎07-05-2012

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 12.12.12.1 > 10.1.0.1: icmp: 5.5.5.1 unreachable - need to frag (mtu 1434) 
     11: 13:48:32.618742 12.12.12.1 > 10.1.0.1: icmp: 5.5.5.1 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.

Thanks.

mateja.jovanovic · ‎02-04-2013

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