Showing results for 
Search instead for 
Did you mean: 

ASA ACL logging return traffic


I have an ASA running 8.0(4).  I am auditing the connections that are flowing through the firewall.  I have done this by adding an 'ip any any log' rule to the end of my configued ACL's so that I can see what type of traffic is not matching.

What I am seeing in the log is what looks like return traffic, or the SYN/ACK from a connection attempt.  It is confusing because the log shows the source and destination to be opposite of what I would expect.  I would expect the firewall to maintain state and the ACL to not care about return packets.  Is this standard behavior on the ASA, or is this a bug?  Is there a way to suppress this output if it really is just return packets that the ASA will allow by default.

14 Replies 14

Phillip Strelau
Cisco Employee
Cisco Employee

Hi Patrick,

     Most likely there is a connection timeout happening on the ASA and when the outside host goes to respond, the ASA has no connection table entry for this packet, and the packet drop is logged. If the ASA had a connection table entry for this traffic you would not be seeing this log. I would suggest capturing all traffic going to the remote host to confirm that this is the case.


Thank you for the reply.  I'm fairly confident that the connection is not timing out, however.  The logs clearly indicate that it is allowing these connections, not dropping them.  If there were timeouts, the ASA would drop the packet right away and it would not show up as a permited connection through the ACL.  At least that is the behavior I have always seen on the ASA when it receives a connectionless packet.  Also, there are no indication that connectivity is failing to the servers.

Has anyone else seen this behavior?

I am seeing the similar behavior. I am using IOS 8.05(23) on a ASA 5520.

There are two interfaces, inside and outside. The connection is initiated from inside, it is allowed by a specific ACE. The connection is working fine but the return traffic is causing hits on the last (any any ip accept) ACE on the outside interface. This is not for the majority of traffic, I guess only for the 5% of the traffic.

I issued the command clear asp drop and after about 4-5 hours ran the command show asp drop. Here are the results:

ASA5520# sh asp drop

Frame drop:
  Flow is denied by configured rule (acl-drop)                                 5
  First TCP packet not SYN (tcp-not-syn)                                    1288
  TCP failed 3 way handshake (tcp-3whs-failed)                                 1
  TCP RST/FIN out of order (tcp-rstfin-ooo)                                    8
  TCP packet SEQ past window (tcp-seq-past-win)                                1
  TCP RST/SYN in window (tcp-rst-syn-in-win)                                  88
  TCP packet failed PAWS test (tcp-paws-fail)                              15121

Last clearing: xxxxxxxxxx

Flow drop:
  Inspection failure (inspect-fail)


Thank You

Andrew Ward

Patrick, I am trying to do exactly the same as you and have come across the same issue. Did you manage to get a solution?

Anyone else have any knowledge of this? It seems very strange that you cannot log a successful connection through an ASA without getting getting loads of syslog messages (message ID 106100) which actually represent the return traffic. As Patrick points out, it's like the SYN-ACK is causing a hit on the ACL line. Here's an example:

Jul 19 2011 15:31:16: %ASA-6-106100: access-list Inside permitted tcp Inside/ -> DMZ/ (3423).......

(Here was a telnet session actually initiated from the DMZ).

So even if I get a perfect rule set above the 'permit any any' I'll still get junk messages like this in my syslog.

Thanks, Andy.

Hi Andrew,

The return apckets would be logged on the ASA, but yes if you want to suppress these logs on the ASA, you acn try:

no logging message 106100

it would suppress this log on ASA.

some helpul docs:

hope that helps.



Varun Rao


No, I never did get a satisfactory answer on this. 


I cannot suppress the log as you indicate because I do want the valid logging for SYN packets that hit rule.  Supressing the 106100 log messages would suppress those as well.

This really seems like a bug to me unless Cisco thinks it is a useful feature.  If so, I would like to know if there is a way to disable the return packet logging.

I would need to verify it, but don't worry would definitely get back to you guys.



Varun Rao


the only work around I can think of is to add some subnet specific uni-directional access-list lines above the 'permit any any log' rule. For example, if your inside subnets all fall in the range you could use:

access-list OUTSIDE_IN permit tcp any any log

This way you wouldn't get any hits on this ace for the return traffic, but if you've got a large number of complex subnets on the outside and the inside (not to mention other) interfaces then it could be tricky.

Do you think such an approach would help your audit?




Hello There,


6 years later I am in a same situtation. Try to filter out what exact traffic using a specific ACE but my logs are full because it somehow catches some return traffic. Have you had chance to find any solution for this issue? Do we need open a Cisco TAC case? 


I have tried to change the "any"keyword for some specific subnets. Also changed the "ip" to "tcp and udp"but the results are the same. Not all the return connection cathced only some of them. Not sure why.

Version: 9.6(3)1


Thank you for your reply in advance,

Kind Regards,


Having the same problem.   Anyone ever determine a solution for this?  Seems like a logging bug to me.

I have heard this is a logging bug, can anyone from Cisco confirm this, and if it was fixed in a published update as of yet? 9.6.4? or Other?

Thank you

I have the same issue. It's weird though, as someone mentioned above, I'm not seeing return traffic for all of my traffic, just a select few. Why is this happening? Why is it logging return traffic for some but not others. I agree that the session is not timing out, the ASA would not allow this traffic otherwise. 


Same issue here. Quite challenging...

For me this small % is still ALOT of traffic. I suppose there is not fix for this? 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers