ASA ACL Logging

[aeryilmaz]

Hi all,

Running ASA 5520 8.2(1)

I have an interface ACL applied, with a catch all at the end for logging traffic that does not match my specific rules.

    access-list dmz-in extended permit ip DMZ-NET 255.255.255.0 any log informational interval 300

I see logs showing that reply packets are hitting that ACL rule. I am confused as to why an established connection, that originated from the Internet, would log hits on an ACL applied to the DMZ interface. Could someone help me to understand what I am seeing?

Thanks in advance!

Example log entries.

%ASA-6-106100: access-list dmz-in permitted tcp dmz/10.10.100.50(80) -> outside/pu.bl.ic.ip(38219) hit-cnt 1 300-second interval [0xc6c51367, 0x0]

%ASA-6-106100: access-list dmz-in permitted tcp dmz/10.10.100.55(443) -> outside/pu.bl.ic.ip(54251) hit-cnt 1 first hit [0xc6c51367, 0x0]

[varrao]

The firewall shouldn't do it, I woudl suggest change the access-list to the following:

    access-list dmz-in extended permit ip DMZ-NET 255.255.255.0 any log informational interval 1

Go to the ASDM, right click on the access-rule, right click -------> show logg ----------> now check what traffic is hitting the acl, it woudl show you the source and destination for the traffic.

Hope this helps you.

Thanks,

Varun

[aeryilmaz]

Thanks, Varun. Changing the logging interval did not make a difference. Not sure if I was clear in my question... I see the source and destination IPs (I did not show the real IPs in the logs above). But, I do not understand why I see ACL hits for replies to TCP traffic that originated from the outside and is currently in an Established state.

In my logs I see source ports http and https, and those packets are replies to HTTP/HTTPS connections.

I shouldn't need an ACE to permit TCP reply packets, so I'm puzzled as to why I see the hits on the access-list.

Thanks.

[aeryilmaz]

I opened a TAC and got the answer to my question:

"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 adaptive security appliance and being evaluated by the access list. For
example, if an ACK packet is received on the adaptive security appliance
(for which no TCP connection exists in the connection table), the adaptive
security appliance might generate message 106100, indicating that the packet
was permitted; however, the packet is later correctly dropped because of no
matching connection."

In my case, the client side is sending in a FIN, the server replies and the ASA tearsdown the connection. It then processes the reply packet against the ACL and since the connection is torndown, the ACL hit is logged.