New interface not passing traffic

[Brian.bsi]

I have a set of 5545's Running multi context. I have added the interface to the correct context. I have created the inside interface and have an IP on it which is able to ping systems on the inside. I have created access-list for the new interface and have tied it to the interface though the access-group command. For some reason the packet is still getting dropped. I am trying to pass icmp to 10.41.10.10 (docker) from 10.6.1.56 (campus). The Packet tracer says denied but I am not sure what I am missing. Can any one see in the below trace output why it is being dropped other than the "configured rule". Question What configured rule?

# packet-tracer input docker icmp 10.41.10.10 1 1 1 10.6.1.56 detial

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 via 10.41.0.17, campus

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x7ffefee30e60, priority=500, domain=permit, deny=true
hits=1523, user_data=0x8, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0, dscp=0x0
input_ifc=docker, output_ifc=any

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

##########

I found this in the log.

6|Sep 27 2018 15:04:48|302020: Built inbound ICMP connection for faddr 10.6.1.56/1 gaddr 10.41.10.10/0 laddr 10.41.10.10/0
3|Sep 27 2018 15:04:48|201008: Disallowing new connections.
6|Sep 27 2018 15:04:50|302021: Teardown ICMP connection for faddr 10.6.1.56/1 gaddr 10.41.10.10/0 laddr 10.41.10.10/0
6|Sep 27 2018 15:04:53|302020: Built inbound ICMP connection for faddr 10.6.1.56/1 gaddr 10.41.10.10/0 laddr 10.41.10.10/0
3|Sep 27 2018 15:04:53|201008: Disallowing new connections.
6|Sep 27 2018 15:04:55|302021: Teardown ICMP connection for faddr 10.6.1.56/1 gaddr 10.41.10.10/0 laddr 10.41.10.10/0

[paul driver]

Hello

the traffic is being implicit dropped meaning it hitting the default deny any any of an access list 

check your acl config

[Marius Gunnerud]

You would need to post your running configuration as the output of the capture doesn't really tell us what is dropping it.  The implicit rule drop can be an incorrect ACL configuration, or it could be a missing configuration such as same-security-traffic command, or something else for that matter.

Please post you full running config, remove any usernames, passwords and public IPs.

[paul driver]

hello

---

@Marius Gunnerud wrote:

You would need to post your running configuration as the output of the capture doesn't really tell us what is dropping it. 

Can you elaborate on why you say the packet capture isn’t reporting anything ? -  looking at the OP post of that capture in my view it does show traffic is being dropped due the default implicit rule of an aacl 

[Marius Gunnerud]

I am not saying that it is not the actual ACL which is dropping the traffic, what I am saying is that it doesn't have to be an incorrect ACL.  So long it is a rule that is for transit traffic that is dropping due to a misconfigured og missing rule the traffic it will be identified as an acl-drop.  For example,  Lets say you have two interfaces with security-level 100 but you do NOT have same-security-traffic permit inter-interface configured.  The output of the packet tracer would be the following:

interface Ethernet0
nameif Inside
security-level 100
ip address 10.11.11.10 255.255.255.0
!
interface Ethernet1
nameif Outside
security-level 100
ip address 192.1.20.10 255.255.255.0

ASA# show run same-security-traffic
ASA#

ASA# packet-tracer input inside icmp 10.11.11.1 8 0 192.1.20.2
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

[Brian.bsi]

I figured this out with Tac. It was a tcp syslog issue/bug. It was not allowing new connections with the tcp syslog server not answering all the time. I had to remove all syslog settings from the whole firewall and reboot to fix the issue.