09-28-2011 08:32 AM - edited 03-11-2019 02:31 PM
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]
09-28-2011 10:49 AM
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
09-28-2011 11:21 AM
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.
09-29-2011 01:35 PM
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.
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