07-31-2010 09:49 AM - edited 03-11-2019 11:19 AM
Has anyone came across issues with icmps on the ASA running on the 8.3 (1) code? I've been trying get inside hosts to ping external hosts but coming back as no replies?
I've made changes to the inbound access-list and even turned off "inspect icmp" but have been unsuccessful so far. Outbound www's work fine.
Attached is a sample config.
Solved! Go to Solution.
08-02-2010 05:55 AM
Hi Jerome,
Your config looks correct. I think it's the packet tracer command that is giving you the trouble. You specified the packet as type 0, code 8 when really the the packet inbound on the inside interface should be type 8, code 0 (echo request). If you swap those numbers around on the packet tracer the packet should be allowed.
Have you tried pinging a host on the outside from a host on the inside since you started making config changes? You should be seeing replies. If not, I would suggest setting up a capture like this:
capture capin int inside match icmp any any
capture capout int outside match icmp any any
Take a look at the captures and see if the ICMP packets are reaching the ASA.
Hope that helps.
-Mike
08-02-2010 06:44 AM
Hello Jerome,
I tried your configuration on one of my test firewalls and I did not have any trouble getting ICMP through it. My test device was 5510 though. One possibility for this behavior could be that you are exceeding the host limit on the ASA (if you have base license). Can you post the output of "show xlate count" and "show conn count" here?
Regards,
NT
07-31-2010 09:57 AM
Hello,
Are you using outside interface IP when pinging to internet? Can you try
"icmp permit any interface outside" and see if that helps?
Regards,
NT
07-31-2010 11:01 AM
I forgot to include that in the config file but its there...
icmp unreachable rate-limit 1 burst-size 1
icmp permit host 0.0.0.0 inside
icmp permit any inside
icmp permit any outside
This is the output of the packet-tracer utility.
Orion-ASA# packet-tracer input inside icmp 192.168.0.7 0 8 4.2.2.2 detailed
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 outside
Phase: 2
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xc9ccc500, priority=0, domain=inspect-ip-options, deny=true
hits=6065947, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 3
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0xc9ccc168, priority=66, domain=inspect-icmp-error, deny=false
hits=26, user_data=0xc9ccc050, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
src ip/id=0.0.0.0, mask=0.0.0.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=any
Phase: 4
Type: NAT
Subtype:
Result: DROP
Config:
object network obj-192.168.0.0
nat (inside,outside) dynamic interface dns
Additional Information:
Forward Flow based lookup yields rule:
in id=0xca943968, priority=6, domain=nat, deny=false
hits=5994843, user_data=0xc6aac410, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=192.168.0.0, mask=255.255.255.0, port=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0
input_ifc=inside, output_ifc=outside
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
08-02-2010 05:55 AM
Hi Jerome,
Your config looks correct. I think it's the packet tracer command that is giving you the trouble. You specified the packet as type 0, code 8 when really the the packet inbound on the inside interface should be type 8, code 0 (echo request). If you swap those numbers around on the packet tracer the packet should be allowed.
Have you tried pinging a host on the outside from a host on the inside since you started making config changes? You should be seeing replies. If not, I would suggest setting up a capture like this:
capture capin int inside match icmp any any
capture capout int outside match icmp any any
Take a look at the captures and see if the ICMP packets are reaching the ASA.
Hope that helps.
-Mike
08-02-2010 06:44 AM
Hello Jerome,
I tried your configuration on one of my test firewalls and I did not have any trouble getting ICMP through it. My test device was 5510 though. One possibility for this behavior could be that you are exceeding the host limit on the ASA (if you have base license). Can you post the output of "show xlate count" and "show conn count" here?
Regards,
NT
08-06-2010 11:24 AM
Mirober & Nagaraja,
The issue was caused by the number of "inside hosts" exceeding the license count. When we upgraded the license count of the firewall, icmps were working fine. Mirober, you were also correct with the code/type being transposed.
Thanks...
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: