ASA Unfound ACL hits

Unanswered Question
Oct 28th, 2008

Hello all. I have a 5540 that I am having what I deem as odd ACL hits. The ASA is currently setup to allow traffic on the outside interface to a protected server on the inside interface. I currently have a permit ip any any applied to the inside interface in. I am seeing acl hits on the inside interface for traffic that is originating from the outside going to the inside. I now have to generate specific ACLs on the inside interface. My problem is that these inside ACL hits have random destination ports because the connection originates from the devices on the outside. This is going to make it difficult to write specific ACLs. I thought once a connection was built through the firewall traffic for that IP and port is allowed back not hitting the destination port. This is kind of confusing hopefully I explained it enough. I am running 7.0(8) and have not found any bugs or anything related to this so far.

Any help would be greatly appreciated.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Jon Marshall Tue, 10/28/2008 - 07:24


You are correct in your assumption. If a connection originates from outside and is allowed through to the inside because of the acl on the outside interface then the return traffic is not checked against the inside acl. It doesn't need to be because that is the whole concept of a stateful firewall.

Where it could have an effect is

1) A protocol that the firewall cannot be stateful for eg. GRE - you would need to allow it back out if you had an acl on the inside interface.

2) An application that generates a "back" connection so the original connection is initiated from the outside and then the server generates a new connection back out. Most apps do not fall into this category.


ckrinock Tue, 10/28/2008 - 07:41

Thank you for confirming.

These are standard TCP connections. The admins say that there are no reverse connections happening. Guess I may need to open a TAC to see if there is a bug out there that I couldn't find.

Thank you again


This Discussion