cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1309
Views
5
Helpful
3
Replies

ASA bypassing ACL rules but matching other below

ricardo.docchio
Level 1
Level 1

Hi everyone

 

I'm having this rare issue in which i have an inbound ACL with a "permit any any" rule at the bottom that is logging its matches so i can declare the application traffic on top of it and delete this unsecure rule .

 

The thing is i have configured the new specific rules of some connections but i'm still getting logs for the "permit any any" for those, for instance:

 

Access-list Rules:

access-list ACL_PROAPP_IN line 79 extended permit tcp host 10.94.2.11 host 10.128.67.103 eq https (hitcnt=13) 0x47b1b5c4

access-list ACL_PROAPP_IN line 99 extended permit ip any any log alerts interval 300 (hitcnt=29770525) 0xd61e0a69

 

LOG:
Jan 13 16:21:36 X.X.X.X %ASA-1-106100: access-list ACL_PROAPP_IN permitted tcp PROAPP/10.94.2.11(49543) -> INTRADC/10.128.67.103(443) hit-cnt 1 first hit [0xd61e0a69, 0x00000000]
Jan 13 16:21:36 X.X.X.X %ASA-1-106100: access-list ACL_PROAPP_IN permitted tcp PROAPP/10.94.2.11(49542) -> INTRADC/10.128.67.103(443) hit-cnt 1 first hit [0xd61e0a69, 0x00000000]
Jan 13 16:21:36 X.X.X.X %ASA-1-106100: access-list ACL_PROAPP_IN permitted tcp PROAPP/10.94.2.11(49548) -> INTRADC/10.128.67.103(443) hit-cnt 1 first hit [0xd61e0a69, 0x00000000]
Jan 13 16:21:36 X.X.X.X %ASA-1-106100: access-list ACL_PROAPP_IN permitted tcp PROAPP/10.94.2.11(49546) -> INTRADC/10.128.67.103(443) hit-cnt 1 first hit [0xd61e0a69, 0x00000000]

Note that the ACL rule identification number on those logs corresponds to the unsecure rule, and the specific rule (created on Dec 23 00:25:32) has already hitcounts. If i emulate the connection with the packet-tracer command, i always get the specific rule as working perfectly. It seems like in a random way this ASA is bypassing some rules. I'm worried about if i delete this "permit any any" rule i get some connections denied.

 

In terms of CPU usage this device is below 15% average usage and 40% for the peaks, and this occurs on low traffic volume hours. Its IOS is 9.8(4)

 

Do you know what can be doing this behavior? 

EDIT: I think the problem can be related to a DNS problem, this rules are created with FQDN objects so i can manage the application  nodes with records in our internal DNS and a single rule. Maybe when the DNS cache on the ASA refreshes, those rules stop working. I dont see connectivity issues to our DNS servers and others rules configured in the same way doesnt seem to present this problem. Now i replaced a FQDN object rule with a explicit IP as a Test

 

3 Replies 3

Hi,

Can you type 'show access-list | i 0xd61e0a69' and see what ACLs will pop
out.


***** please remember to rate useful posts

Hi Mohammed

 

The output of the command is the "permit ip any any" rule:

access-list ACL_PROAPP_IN line 99 extended permit ip any any log alerts interval 300 (hitcnt=29908463) 0xd61e0a69

 

As i wrote in the edit of the post, i think the issue is related to DNS resolution, i found this discusion about FQDN access-lists and i tried increasing the DNS expire-entry-timer from 1 minute to 5 minutes

 

https://community.cisco.com/t5/security-documents/using-hostnames-dns-in-access-lists-configuration-steps-caveats/ta-p/3123480#toc-hId--1214252331

 

So far i dont have new logs for the "permit any any" access-list rule, so i think it worked

 

 

Aha, I didn't notice that you are using fqdn instead of IP in your ACL. If
that is the case then very possible to be that domain not resolved
properly.

******* please remember to rate useful posts
Review Cisco Networking for a $25 gift card