Access List not Catching Traffic

[Nathaniel Wood]

Hello Everyone,

I've recently run into an issue that I haven't experienced before, and I can't find any information specific to my particular issue. I recently had to allow any any access from our internal network to a server on our DMZ as the developer of that particular server had no idea what IP's and ports it communicates to and over. 

After reviewing my FW logs it seems my ACL is not catching the traffic early on in the ACL at line 7&8 and it's finding its way down to line 132. The ACL outputs are as follows:

access-list inside-in line 7 extended permit tcp host 10.X.61.96 10.X.13.0 255.255.255.0 eq ldap    

access-list inside-in line 7 extended permit tcp host 10.X.61.97 10.X.13.0 255.255.255.0 eq ldap

access-list inside-in line 8 extended permit udp host 10.X.60.100 10.X.13.0 255.255.255.0 eq domain

*********************************ADDITIONAL ACL STATEMENTS**********************************************

access-list inside-in line 125 extended permit ip any host 10.X.13.44

********************************END OF OUTPUT*****************************************************************

Line 125 is catching connections for the specific .44 host that should be caught by line 7 and 8 because they encompass that particular subnet.

Has anyone ever run into this? Am I overlooking something in the ACL rule hierarchy, as I thought it works top down.

Thanks for any help you can provide.

[Jon Marshall]

It does work top down but are you sure the traffic was for the specific TCP ports in lines 7 & 8 ?

If the developer couldn't tell you which ports are being used how do you know you should be seeing hits on those lines ?

Jon

[Nathaniel Wood]

Hi Jon,

Yes, the traffic is sourced from those hosts to the specific host of .44 over TCP port 389 and UDP port 53 which according to the syntax in the ASA is ldap and domain, respectively.

I know I should be seeing hits on those lines because my "catch all" statement to monitor the traffic is getting hits from those specific hosts to the host of .44 over those ports.

Because the developer couldn't tell me what IP's and ports are used we left an "any any" statement to allow all traffic to that host internally and I am progressively locking down the rules until I have little or no ACL hits for the "catch all" statement.

[Jon Marshall]

I notice that the source IPs are not being allowed for both ports and maybe that is the issue but i don't want to offend you by saying the obvious.

Have you tried a packet-tracer test to see which acl line it is hitting ?

All I can say is that it has to run from top down otherwise you couldn't logically control your access rules correctly.

Jon

[Nathaniel Wood]

Hi Jon,

I appreciate your courtesy, but I won't get offended especially if it's something I overlooked. Sometimes a fresh set of eyes is all that is needed.

That being said - those three statements at the top of the ACL are what should be catching the traffic, but it seems to make its way down to the bottom line I mentioned above.

I showed it to some colleagues of mine who are better versed with firewalls, and they said all my configurations look correct so I figured I would reach out to the support community.

[Jon Marshall]

Sorry, that should read -

"packet-tracer input inside tcp 10.16.x.96 1024 10.x.13.44 389"

Jon

[Jon Marshall]

Did you try a packet-tracer test ie.

"packet-tracer input tcp 10.16.x.96 1024 10.x.13.44 389"

and see what it shows ?

Jon