Hey, people, welcome to this new series that I have called “CCNA Security—Solutions to Frequently Asked Challenges (FACs)”. The reason I did not use the more common “FAQ” abbreviation is that it is not to be confused with “administrative” questions relating to the CCNA security exam, such as the question format or number of questions. In this series, we will be taking on challenges that are frequently asked by those preparing for the CCNA Security certification exam and drilling down into the solution for those challenges. Therefore, be sure to add your challenges in the comments section.

ICMP on the Cisco ASA

When I first began using the ASA (PIX at that time), it was a new environment for me, having spent a lot of time with the Cisco IOS, which the routers and switches use. The Cisco ASA is a security appliance and it was built with that purpose in mind; therefore, a lot of the things you may be familiar with from the Cisco IOS do not work on the Cisco ASA. Also, there are totally new concepts on the Cisco ASA that are not in the Cisco IOS.

One such concept is Security Levels. You probably learned that the ASA segments networks (or its interfaces) into zones making use of security levels. Interfaces can be assigned security levels between 0 and 100; interfaces connecting to the LAN are usually assigned a security level of 100 while those connecting to a public network are usually assigned a security level of 0. DMZs are assigned security levels between 1 and 99.

So how do security levels affect anything on the ASA? To explain this concept, I like using the analogy of a waterfall. The way water can only flow from a higher level to a lower level (by default) in a waterfall, that is the way traffic can only flow from a higher security level to a lower security level by default on the Cisco ASA. The diagram below explains this concept.

So why did I start this article with an introduction to security levels and default traffic flow on the Cisco ASA? It is because we want to talk about a “weird” issue with ICMP on the Cisco ASA. Let us create a simple network for testing purposes.

I have done the basic configuration on all devices. To confirm this, I will issue ping packets from both sides. Also, the routers have the ASA as their default gateway.

The Challenge

Issuing ping packet is “natural” for every network administrator to test connectivity. Knowing that the ASA should allow traffic from the higher security level to the lower security level by default, you will now probably want to check that the InsideRTR can ping the OutsideRTR.

If you are not familiar with the ASA, you will be thrown into a frantic search for the error in your configuration. Moreover, you will likely not test other kinds of traffic because you will be thinking, “If ping doesn’t work, what will work?” That could not be farther from the truth. Let us initiate a telnet session from the InsideRTR to the OutsideRTR.

By now, you will probably have your mouth open, like “What??” So we have established that a telnet session is opened but that ICMP is not going through. This rules out routing as the problem. If you are in a lab environment or non-production environment and are familiar with debug commands, you will want to look at the debugs on the other end. Therefore, let’s turn on ICMP debugging on OutsideRTR and run the ping again.

From the above, we can see that not only does the ping packet get to the OutsideRTR, that router also sends replies. Where then is the problem? The only other place to look is the ASA because it is the only other device in the network.

Since this is CCNA level, I will not go deeply into the logging output shown above, but notice the highlighted portion: The inbound ICMP reply packet from to is denied.

The Solution

“Well,” you will think, “this goes against the default traffic flow concept on the ASA.” In a way, you are right, because ICMP traffic is the exception to the default stateful nature of the ASA. By default, the Cisco ASA does not inspect ICMP traffic, meaning it will not automatically allow return ICMP traffic even if such traffic originates from a higher security level interface.

So how do we go about correcting this? There are two ways. The first way is to edit the default policy configuration on the ASA. This default policy is shown below:

We can add an “inspect icmp” statement under that policy map, thus instructing the ASA to perform ICMP inspection.

Let’s test our ping functionality again.

Aha! We have a positive response. Let’s look at the second (less recommended) way. Remember we said the ASA has a default traffic flow; this default flow can be altered by using access lists. By applying an ACL on the outside interface, we can explicitly allow ICMP return (echo-reply) packets. (You can also enable all ICMP packet types; it just means hosts on the outside can initiate ping traffic to hosts on the inside).

We will turn off the first solution we configured (ICMP inspection) and then configure an access list.

Let’s try to ping again from InsideRTR.

Success! To confirm that it is our access list that makes this happen, we will look at the ACL counter on the ASA.

Before we round this off, one more thing to note: The implicit deny all that is on the ACL we applied on the outside interface does not affect the normal stateful nature of the ASA, i.e., that ACL will not deny return traffic to normal inspected traffic; it will only prevent traffic initiation from the outside. To verify this, we will open our telnet connection from the InsideRTR to the OutsideRTR as before.


Cool. In this article, we kicked off the series on solutions to CCNA Security frequently asked challenges. We looked at the challenge of ICMP traffic on the Cisco ASA. We discussed the fact that ICMP traffic defies the default traffic flow on the ASA because the ASA does not automatically allow echo-reply packets back, even if the corresponding echo packet was initiated from an interface with a higher security level. We then considered the two solutions to this challenge: ICMP inspection and access lists.

Not only will this help you in your CCNA Security exam, it will also give you a strong foothold in your knowledge about the Cisco ASA in general. In the next article in this series, we will be looking at the Cisco Configuration Professional (CCP) tool, which I found some complaining about during their prep.

I hope you have found this article insightful and, as I said before, let us know (using the comment section below) what topics you will like treated and we can add it to the stack! See (or write?) you soon.

Further reading