Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

ASA 5505 9.1(2) icmp issue.

 

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

Version history
Revision #:
2 of 2
Last update:
‎08-29-2017 03:32 AM
Updated by:
 
Labels (1)
Contributors