02-06-2015 11:39 AM - edited 03-11-2019 10:28 PM
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.
02-06-2015 12:04 PM
Can you share the config, output of packet tracer and a quick sketch/diagram that shows your layout?
02-06-2015 05:37 PM
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
02-06-2015 05:37 PM
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!
02-06-2015 06:15 PM
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?
02-07-2015 04:49 PM
02-07-2015 05:43 PM
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?
02-07-2015 05:46 PM
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.
02-07-2015 06:40 PM
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...
02-08-2015 02:22 PM
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?
02-09-2015 07:35 AM
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.
02-09-2015 09:50 AM
do not associate access-list to ASA inside interface at all and see what happens.
02-09-2015 10:27 AM
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.
02-09-2015 01:17 PM
Turns out the issue was a NAT created directly with an interface which drops all traffic.
02-09-2015 09:55 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide