Introduction
This document describes 2 scenarios faced by different users regarding ICMP drop on ASA 9.1(2).
Problem
Scenario 1: ICMP packet drop from inside to outside.
ASA upgradtion from 8.4.x to 9.1.2
Found drop in ICMP from inside to specific servers on Internet.
When User ping from a server or host on the inside he get the drop-reason nat-no-xlate-to-pat-pool with pacet tracer.
If he ping from the ASA it works as It should.
ex. ping 8.8.8.8
it works fine.
Scenario 2: ICMP packet drop from outside to inside.
This is the scenario described by the user:
Provider gave a public space address 93.XX.XX.160/27
Provider's router ip address is 93.XX.XX.161
ASA outside interface ip address is 93.XX.XX.162
Proxy ARP and ICMP inspection are enabled on Outside interface
User have succesfully configured a netowrk object static PAT rule , allowing https requests incoming from outside to reach his web server in DMZ , inside global address is 93.XX.XX.163 . User has also configured an inbound access-list applyed to outside interface that allows https traffic form outside addresses to his DMZ webserver. All works fine and he can see traffic flowing from outside to our webserver looking at system logs.
Now user would like to enable ICMP from outside addresses to inside global address 93.XX.XX.163 .
The first thing he noticed is that every request from every outside address incoming to 93.XX.XX.163 does not arrive at ASA' s outside interface , unless it's directed to https (the static translated) port .
So he executed packet tracer :
Command used: packet-tracer input outside icmp 8.8.8.8 1 1 93.XX.XX.163
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 93.XX.2XX.160 255.255.255.224 outside
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate
Scenario 3
User is running into an odd situation with DMZ config on 9.0(3). User manage to get it to work with an ANY statement. But user not satisfied with implementation using "Any" statement
So below is current traffic is
INSIDE--------------------------> DMZ --------nat-------->OUTSIDE
192.168.3.4/24 192.168.1.55 x.x.x.55
Right now 192.168.1.55 (DMZ) can reach both inside and outside perfectly fine. However, because user uses an ANY statement, the host in DMZ is actually able to reach the entire INSIDE subnet. User don't want that. User just want it to be able to reach 192.168.3.4 only.
Solution
Scenario 1: ICMP packet drop from inside to outside.
This is a known issue in 9.x NAT behaviour. We cannot say it is a bug, but it is a re-design for NAT.
The issue occurs when request is made for non-mapped service on a host,for which static identity NAT is configured along with service port translation (either identity or non-identity).
For example, with following NAT rule:
object network MyServer
host 2.1.11.2
nat (outside,inside) static MyServer service tcp www 8080
Making a request to the mapped (outside host) port 8080 from inside host works fine; however request for other services on the outside server (such as SMTP) doesn't go through.
Workaround
To make other services on the outside server accessible, configure explicit NAT rule to allow the services. For example, to allow access to HTTP as well as SMTP service on above server, configure:
object network MyWWWServer
host 2.1.11.2
nat (outside,inside) static MyWWWServer service tcp www 8080
object network MySMTPServer
host 2.1.11.2
nat (outside,inside) static MySMTPServer service tcp smtp 8025
This issue has been documented in a DOC bug, but it is still not available in Cisco.com bug toolkit.
Scenario 2: ICMP Packet drop Outside to Inside.
If user have used a free public IP address from the subnet the ISP allocated and done Static PAT (Port Forward) for port TCP/443?
If this is the case then user wont be able to send ICMP from the public network for this server.
Since user have a decent sized public subnet at your disposal he should try configuring Static NAT instead of Static PAT and just allow ICMP Echo on the "outside" interface inbound ACL.
So Let's assume user have this at the moment
object network STATIC-PAT
host x.x.x.x
nat (inside,outside) static 93.x.x.163 service tcp 443 443
Suggested configuring Static NAT
object network STATIC-NAT
host x.x.x.x
nat (inside,outside) static 93.x.x.163
This would enable contacting the internal server which any service that you allow in the ACL.
Scenario 3: DMZ host should be able to access internet.
As we all know firewall needs an access-list to permit traffic that comes from a lower security level to a higher one. Once you create the inbound access list on the DMZ to permit the specific host on the inside if you don't permit traffic from the source to any you are going to lost connectivity to the internet.
The way to work this is to use the access-list to permit what you need and then deny what you don't using the hierarchical properties of the acl.
It goes something like this:
nameif outside
security-level 0
ip address 66.111.20.252 255.255.255.0
nameif dmz
security-level 50
ip address 192.168.1.251 255.255.255.0
nameif inside
security-level 100
ip address 192.168.3.250 255.255.255.0
First you permit from DMZ to inside (lower to higher)
EX:
access-list dmz_access_in permit ip object Hieu-DMZ-Laptop object CORE-Management-VLAN2--->with this one you include what you need to allow.
access-list dmz_access_in deny ip any 192.168.3.0 255.255.255.0----> on this one you deny access to the inside network.
access-list dmz_access_in permit 192.168.1.0 255.255.255.0 any ----->With this one you permit access from the DMZ range to the internet.
Source Discussion
