ASA generate ACL HIT on non syn packets

[rstockum]

Hello

we are wondering since some time about strange log entries of our ASA 5545 with the version Cisco Adaptive Security Appliance Software Version 9.12(4)62
Namely response packets generate a first hit of the access list at the input interface of the response packet.
Why does the access list register a first hit on a non syn packet? For example:

%ASA-5-106100: access-list dmz_access_in permitted tcp dmz/192.168.100.10(1352) -> inside/192.168.200.50(49655) hit-cnt 1 first hit [0xd6e03752, 0x000000]

In this case the host 192.168.100.10 is a lotus-notes server and the inside host is a client.
The expected first acl hit should be:

%ASA-5-106100: access-list inside_access_in permitted tcp inside/192.168.200.50(49655) -> dmz/192.168.100.10(443) hit-cnt 1 first hit [0xc36ca4bb, 0x00000000]

The access lists looks like this:

access-list inside_access_in extended permit tcp object NET-SV-192.168.200.0_24 object NET-DMZ-192.168.100.0_24 eq lotusnotes log notifications

access-list dmz_access_in extended permit ip object NET-DMZ-192.168.100.0_24 object NET-SV-192.168.200.0_24 log notifications

For out of state packets I actually expect a drop (no connection) and otherwise an acl match only for syn packets. But not an ACL Match for the response packets.

Does anyone have an idea why this is the case?

[MHM Cisco World · Accepted solution]

The first non sync packet match acl 

And timeout if end and it still non sync the conn will remove.

Not acl how can filter sync and non sync but the inspection and timeout remove non sync packet.

[rstockum]

Hi - thanks for your replay!

The ASDM real-time log viewer gives this explanation:

"When an access-list line has the log argument, it is expected that this message ID might be triggered because of a nonsynchronized packet reaching the ASA and being evaluated by the access list. For example, if an ACK packet is received on the ASA (for which no TCP connection exists in the connection table), the ASA might generate message 106100, indicating that the packet was permitted; however, the packet is later correctly dropped because of no matching connection."

However - the appearance of these log entries is confusing at first.