topic I've added all of these rules in Network Security

ASA - implicit deny issue

CSCO12047997 — Tue, 12 Mar 2019 05:28:10 GMT

I am having issues with a new ASA deployment.

I have an inside interface connected and routing into my network (I can ping pretty much everything I need to). The issue is the return traffic. All return traffic seems to be being blocked despite the fact I have an ACL rule explicitly allowing it.

When I ran the packet tracer tool it told me my implicit deny rule was blocking the traffic but why would that be the case if I have a rule specifically allowing this traffic?

Since ACLs rules are read in order shouldn't this traffic never even reach the implicit deny?

Thanks.

Can you share the config,

nspasov — Fri, 06 Feb 2015 20:04:55 GMT

Can you share the config, output of packet tracer and a quick sketch/diagram that shows your layout?

I am attempting to get

CSCO12047997 — Sat, 07 Feb 2015 01:37:00 GMT

I am attempting to get traffic to ethernet 0/1

Its a basic topology.

ASA ethernet 0/1 >>> connecting to a 4500 catswitch

- They are directly connected in the correct subnet/vlan

- The ASA can ping out but the switch can't reach the ASA and according to the packet tracer it is because of the implicit deny rule

The packet capture is on the

CSCO12047997 — Sat, 07 Feb 2015 01:37:01 GMT

The packet capture is on the previous reply.

At one point (since this is in a test environment) I deactivated all the access rules and added an any any allow yet still when I ran the packet capture it would show as the implicit deny blocking the traffic.

I know for a fact that there is connectivity because the ASA can ping out (and both links are fully) but nothing can ping or connect back.

Any help as soon as possible would be very much appreciated!

The first thing that sticks

nspasov — Sat, 07 Feb 2015 02:15:08 GMT

The first thing that sticks out is that I don't see the configured ACLs being attached to any interfaces with the access-group command. Do you not have that or did you just not include it in the post?

I see no rules that would

David paull — Sat, 07 Feb 2015 02:25:14 GMT

I see no rules that would allow 10.20.0.13 -> 10.20.0.200 ICMP traffic whatsoever in your configuration that you provided. The packet-tracer is working correctly.

I've added all of these rules

CSCO12047997 — Sun, 08 Feb 2015 00:49:52 GMT

I've added all of these rules via ASDM. Via the ASM it shows them being applied to the interface I need them too (see image attached). Why would this not show via the CLI?

Basically it seems that

CSCO12047997 — Sun, 08 Feb 2015 01:43:20 GMT

Basically it seems that despite the ACL's being applied to the interfaces in the ASDM they are not reading as applied to the interfaces by ASA. I'm on version 8.0(3) and 6.0(3) respectively.

How can I make these rules work via the ASDM?

If they show up in ASDM, they

David paull — Sun, 08 Feb 2015 01:46:19 GMT

If they show up in ASDM, they are applied (at least in ASDM 6.4 and 7.1 -- although I had no part in setting up ASDM, maybe this isn't default at my org). Are the rules showing hits in ASDM or is the column to the right all 0's?

You haven't commented on the following:

I see no rules that would allow 10.20.0.13 -> 10.20.0.200 ICMP traffic whatsoever in your configuration that you provided.

They are showing up as all 0

CSCO12047997 — Sun, 08 Feb 2015 02:40:36 GMT

They are showing up as all 0's.

Its just odd that they show up as applied on the ASDM but when I use the CLI tool and see the sho run command (pasted earlier in this thread) the ACLs don't show as applied to any interface...

what if you add an 'icmp

APPIREDDY — Sun, 08 Feb 2015 22:22:03 GMT

what if you add an 'icmp inspect' command under inspection_default class?

Also what is the gateway of last resort set to on 4500 switch? What is the default route on 4500 switch?

I am very confident the

CSCO12047997 — Mon, 09 Feb 2015 15:35:40 GMT

I am very confident the routing is fine for a few reasons:

1. The traffic coming FROM the ASA has a path to everything it needs to without issue.

2. The link is directly connected and both link lights and protocols are up.

3. The packet tracer explicitly shows that the implicit deny rule is dropping all traffic.

It's very frustrating actually because I've put in an allow any any at this point for testing as the top ACL yet even with this the packet tracer is showing the implicit deny is blocking all traffic.

do not associate access-list

APPIREDDY — Mon, 09 Feb 2015 17:50:53 GMT

do not associate access-list to ASA inside interface at all and see what happens.

sorry i have noticed the

APPIREDDY — Mon, 09 Feb 2015 17:55:52 GMT

sorry i have noticed the following

access-list inside_access_in extended permit icmp any any

change the above as shown below.

access-list inside_access_in extended permit icmp any any echo-reply 
access-list inside_access_in extended permit icmp any any source-quench 
access-list inside_access_in extended permit icmp any any unreachable 
access-list inside_access_in extended permit icmp any any time-exceeded

Did this. Made no difference

CSCO12047997 — Mon, 09 Feb 2015 18:26:14 GMT

Did this. Made no difference.

Did this as well. Made no

CSCO12047997 — Mon, 09 Feb 2015 18:27:18 GMT

Did this as well. Made no difference. having the Access-lists unassociated was the original setting before this morning. I associated it in an attempt to troubleshoot this connectivity issue.

Turns out the issue was a NAT

CSCO12047997 — Mon, 09 Feb 2015 21:17:33 GMT

Turns out the issue was a NAT created directly with an interface which drops all traffic.