When you first setting up a Cisco ASA firewall, one of the most common requirements is to allow internal hosts to be able to ping the Internet. It is not only for the convenience that a network administrator to check if the Internet is up by pinging Google.com, but also for certain applications to work properly. I have seen network monitoring tools like Solarwinds Orion needs to be able to ping a device before it tries to poll SNMP. In this session, I will cover how to enable ICMP inspection to allow ping traffic passing ASA. There are two ways of enabling ICMP returning traffic to pass the ASA firewall outside interface. However only Option one is recommended.
Enable ICMP inspection to Allow Ping Traffic Passing ASA
By default all traffic from higher security zone such as “inside” going to lower security zone “outside” is allowed without the need of an ACL. Return traffic is allowed while the traffic was initiated from “inside”. This is only true for stateful TCP traffic. You’ll find yourself not being able to ping from an internal host to the outside world without implementing one of the options below.
Option 1: Using “inspect icmp” statement in the global_policy map (recommended)
In case of stateful TCP traffic, the ASA will automatically allow return traffic that is initiated from inside. ICMP traffic do not themselves contain any connection information such as sequence numbers and port numbers. They do however contain source and destination IP addresses. How ICMP stateful inspection is done by the firewall?
The “inspect icmp” will dynamically allow the corresponding echo-reply, time-exceeded, destination unreachable, and timestamp reply to pass through the outside interface (if the ping was initiated from inside) without needing to have access-list to allow.
The permitted IP address of the return packet is wild-carded in the Dynamic ACL. It is wild-card address because the IP address of the return packet cannot be known in advance for time-exceeded and destination-unreachable replies. These replies can come from intermediate devices rather than the intended destination. Think how “trace route” works.
Here is how ICMP inspection is configured on an ASA. This configuration is recommended because dynamic ACLs are generated per session “as needed” basis, and will be removed after timeout value expires.
policy-map global_policy
class inspection_default
inspect icmp
Option 2: Using ACL to allow echo-reply
access-list OUTSIDE extended permit icmp any4 any4 echo-reply
access-list OUTSIDE extended permit icmp any4 any4 time-exceeded
access-list OUTSIDE extended permit icmp any4 any4 timestamp-reply
access-list OUTSIDE extended permit icmp any4 any4 unreachable
The second option is not recommended because static ACLs are created to allow any echo-reply type traffic to enter the ASA outside interface regardless it was corresponding traffic initiated from inside.
Thank you! I was going crazy thinking something was wrong with my NAT configuration, turns out everything was working and this is what I was missing!
I’m having trouble getting the policy-map icmp inspect method to work on my Cisco ASA 5506. I’ve tried these methods:
ACL Method
access-list icmp-allow extended permit icmp any any
!
class-map icmp-class-map
match access-list icmp-allow
!
!
policy-map icmp-policy-map
class icmp-class-map
inspect icmp
!
service-policy icmp-policy-map interface inside
Inspection Method
class-map inspection_default
match default-inspection-traffic
!
!
policy-map global_policy
class inspection_default
inspect icmp
!
service-policy global_policy global
Debug
With either of these applied, I see the following:
firewall# debug icmp trace
debug icmp trace enabled at level 1
firewall# ping googl.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 142.251.215.228, timeout is 2 seconds:
ICMP echo request from 65.129.24.126 to 142.251.215.228 ID=48558 seq=4567 len=72
ICMP echo reply from 142.251.215.228 to 65.129.24.126 ID=48558 seq=4567 len=68
Denied ICMP type = 0, code = 0 from 142.251.215.228on interface 2
?ICMP echo request from 65.129.24.126 to 142.251.215.228 ID=48559 seq=4567 len=72
ICMP echo reply from 142.251.215.228 to 65.129.24.126 ID=48559 seq=4567 len=68
Denied ICMP type = 0, code = 0 from 142.251.215.228on interface 2
?ICMP echo request from 65.129.24.126 to 142.251.215.228 ID=48560 seq=4567 len=72
ICMP echo reply from 142.251.215.228 to 65.129.24.126 ID=48560 seq=4567 len=68
Denied ICMP type = 0, code = 0 from 142.251.215.228on interface 2
?ICMP echo request from 65.129.24.126 to 142.251.215.228 ID=48561 seq=4567 len=72
ICMP echo reply from 142.251.215.228 to 65.129.24.126 ID=48561 seq=4567 len=68
Denied ICMP type = 0, code = 0 from 142.251.215.228on interface 2
?ICMP echo request from 65.129.24.126 to 142.251.215.228 ID=48562 seq=4567 len=72
ICMP echo reply from 142.251.215.228 to 65.129.24.126 ID=48562 seq=4567 len=68
Denied ICMP type = 0, code = 0 from 142.251.215.228on interface 2
I can see that my inside host is being properly translated to my outside interface’s IP (PAT). It seems like the firewall isn’t tracking my ICMP request…