ASA 5505 can Ping Public IPs, Inside Hosts can't Receive Echo Reply

[cruztovar]

I am having problems receiving echo-reply responses to inside hosts when pinging public IPs.  The ASA can ping public IPs and receives the echo replies just fine.  I have an ACL to permit icmp from any source to any destination.  

Inside hosts do have the ability to reach the Internet just fine.  To me it seems like an ACL issue, but with the ACL I have, it seems like I should not have an issue receiving the echo-reply responses.

I have also tried adding additional ACLs like the two statements below, but this did not improve anything.

access-list Outside_ACL extended permit icmp any any echo-reply

access-list Outside_ACL extended permit icmp any any time-exceeded

Below is the relevant config output from the ASA

ASA Version 8.4(7)31
!
interface Ethernet0/0
switchport access vlan 2
!
interface Ethernet0/1
description Dell-N2024-gi1/0/15
switchport access vlan 254
!
interface Vlan2
nameif outside
security-level 0
ip address 100.0.0.100 255.255.255.224
!
interface Vlan254
nameif inside
security-level 100
ip address 192.168.254.3 255.255.255.0
!
access-list Outside_ACL extended permit icmp any any
!
icmp permit any outside
!
nat (inside,outside) source static OBJ-192.168.20.0-24 100.0.0.200
!
access-group Outside_ACL in interface outside
route outside 0.0.0.0 0.0.0.0 100.0.0.30 1
route inside 192.168.20.0 255.255.255.0 192.168.254.2 1
!
policy-map global_policy
class inspection_default
inspect icmp
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect netbios
inspect tftp
inspect ip-options
inspect sip rs-sip

Packet Tracer Results

ciscoasa# packet-tracer input outside icmp 8.8.8.8 0 0 192.168.20.74

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 192.168.20.0 255.255.255.0 inside

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group Outside_ACL in interface outside
access-list Outside_ACL extended permit icmp any any
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: DROP
Config:
nat (inside,outside) source static 192.168.20.0 100.0.0.200
Additional Information:

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

[Marvin Rhoads]

As long as you are inspecting icmp (as you are) the ASA will recognize the initiation of echo requests from inside and allow the echo replies. You don't need the ACL.

You packet-tracer failed because you specified the source being outside and the destination a real inside address.

Your NAT is also incorrect in that it specifies a host where I think you want to specify a subnet as the internal source.

You must have also modified your addresses for posting here as 10.0.0.300 is not a valid IP address. An ASA would not even accept that syntax in the command parser.

[Ajay Saini]

No need for inbound access-list for icmp. ICMP inspection is sufficient to allow echo reply for icmp echo reqeust.

nat (inside,outside) source static 192.168.20.0 100.0.0.200

By this above nat statement, I am assuming that you own a /24 public subnet. Can you try below Nat statement and see if that works(this is specific to a host 192.168.20.74) so test from that machine or any machine you have access to.

object network obj-test

 host 192.168.20.74

nat (inside,outside) 1 source static obj-test interface

If this works, we then need to check the NAT rule you have configured.

also, just to verify, does this subnet 192.168.20.0/24 have internet access?

-

AJ

[Ajay Saini · Accepted solution]

My bad, didn't notice. Marvin is right. The NAT you have is incorrect. Can't have many to one nat for static type. You need a dynamic NAT statement and about icmp, inspect should do.

-

AJ

[cruztovar]

Thank you.  And just to confirm, instead of having the nat be static, it should be set to dynamic as shown below?

nat (inside,outside) source dynamic OBJ interface

[Ajay Saini]

Yes, that is correct. So, in OBJ, you can identify your internal network that needs internet access,

-

AJ

[cruztovar]

Yes I changed my nat statment to dynamic and I can now ping outside hosts.  Thanks AJ and Marvin.