ACL UDP 53 (DNS) Denied With Allow statement

[jbulloch]

Attempting to lock down a subnet to only be able to access certain hosts.

The dns server sits at 157.141.245.10. Initially, i allowed in bound "permit udp <subnet and wc> host 157.141.245.10", but the traffic is still being blocked out to server. So i set "eq domain" and "eq 53" to no success. I've also moved it upwards in the ACL and had no success there either.

It was suggested to me to place "permit udp any any eq domain" and remove the permit, but this too was unsuccessful.

The final deny is:  100 deny ip any any log-input.

Is there something simple i could be missing here?

Thank you.

[paul driver]

Hello

---

@jbulloch wrote:
Attempting to lock down a subnet to only be able to access certain hosts.

---

Can you elaborate on this please, not so sure why you need to deny dns to negate access for certain hosts.
maybe also share a topology of your network?

[jbulloch]

 Hi paul,

Thanks for the reponse. The goal here is not so much to deny dns, but to only allow our subnets that "need" to talk to the dns sever to do so. I am attempting to allow it for this entire network, not a paticular host. Though in a round about way not allowing it for other networks would indeed be negating it for those certain hosts on that network.

The why is because mangement said so. They had an auditing company come in and part of the feed back was restricted traffic to DNS because "it can be hijacked".  So here i am, allowing the permit on udp and tcp but it's still being denied udp even with the adjustments i have tried in my previous post. 

[Mancunian]

Ensure the reverse traffic from the DNS server back to your subnet is allowed
permit udp host 157.141.245.10 eq 53 <subnet wildcard mask>
permit tcp host 157.141.245.10 eq 53 <subnet wildcard mask>

If it's not helped try to temporarily add logging to the permit statements to see if DNS traffic hits them:
permit udp <subnet wildcard mask> host 157.141.245.10 eq 53 log
permit tcp <subnet wildcard mask> host 157.141.245.10 eq 53 log

If traffic is not hitting the rule, check:
Is the ACL bound to the correct interface and direction?
Are there other rules higher up in the ACL that might block or override it?

[MHM Cisco World]

Confirm these points 

1- what is direction of ACL?

2- what is interface you apply ACL is it SVI?

3- add in end of acl deny ip any any log' and check traffic deny' see port and ip use by dns' it can user use public dns server or use tcp instead of udp to connect to server 

MHM

[jbulloch]

Hi everyone, 

Thanks for the feedback. As of now, there is no acl on the server network (i haven't gotten that far), and routing looks fine. I am not seeing these dns hits on other already placed ACL's, only on a few such as this one when i went back and looked. ACLs are set on SVI's, inbound for  the outbound traffic.

I have an ip deny log set as the last statement and i see the deny there. I do not get hits on the permit with log there. There are no other deny statements, i took them out and it still hits the deny. 

[Richard Burts]

Could you tell us about the topology of the network where you are applying the ACL? And would you post the interface configuration and the ACL configuration where the ACL is applied?

[jbulloch]

Hi richard, thanks for the reply!

Here is my ACL currently, it's likely a bit amateurish. Only allowing traffic from the network outwards to the hosts (applied inbound on the svi). Placing the line at the top was my last attempt with a eq domain to fix the issue.

The topology is simple, it's a core to a data center wing and to a user wing. This SVI lives on the core l3 device for the svi on the user side, feeding down to the distro and user level access switches. 

1 permit udp 157.141.116.0 0.0.3.255 host 157.141.245.10 eq domain
    10 permit icmp any any  
    11 permit tcp 157.141.116.0 0.0.3.255 host 157.141.10.12
    12 permit tcp 157.141.116.0 0.0.3.255 host 157.141.10.13
    20 permit tcp 157.141.116.0 0.0.3.255 host 157.141.246.30
    23 permit tcp 157.141.116.0 0.0.3.255 host 157.141.29.23  
    25 permit tcp 157.141.116.0 0.0.3.255 host 157.141.29.22  
    26 permit tcp 157.141.116.0 0.0.3.255 host 157.141.29.24
    29 permit tcp 157.141.116.0 0.0.3.255 host 157.141.29.28
    32 permit tcp 157.141.116.0 0.0.3.255 host 157.141.44.64
    33 permit tcp 157.141.116.0 0.0.3.255 host 157.141.51.111
    35 permit tcp 157.141.116.0 0.0.3.255 host 157.141.138.40
    37 permit tcp 157.141.116.0 0.0.3.255 host 157.141.245.10
    38 permit tcp 157.141.116.0 0.0.3.255 host 157.141.252.13
    39 permit tcp 157.141.116.0 0.0.3.255 host 157.141.252.16
    40 permit tcp 157.141.116.0 0.0.3.255 host 157.141.252.53
    98 permit udp any any eq domain  
    99 permit tcp any any eq domain
    100 deny ip any any log-input  

[Richard Burts]

Thanks for the additional information. The ACL looks like it would pass the DNS traffic. So I am a bit surprised that it is not working. To investigate further would you post the output of the command show access-list? I would like to see which entries have hits.

Also can you verify that devices in that subnet have IP connectivity to the DNS server? Can hosts in this subnet ping the DNS server?

Also I am interested in the last line which denies everything and logs it. Are you seeing messages in the logs showing denied traffic for DNS? If so would you post one or two of those messages?

[jbulloch]

Richard, sure the hits were:

1 permit udp 157.141.116.0 0.0.3.255 host 157.141.245.10 eq domain
    10 permit icmp any any (111923 matches)
    11 permit tcp 157.141.116.0 0.0.3.255 host 157.141.10.12
    12 permit tcp 157.141.116.0 0.0.3.255 host 157.141.10.13
    20 permit tcp 157.141.116.0 0.0.3.255 host 157.141.246.30
    23 permit tcp 157.141.116.0 0.0.3.255 host 157.141.29.23 (3 matches)
    25 permit tcp 157.141.116.0 0.0.3.255 host 157.141.29.22 (2 matches)
    26 permit tcp 157.141.116.0 0.0.3.255 host 157.141.29.24
    29 permit tcp 157.141.116.0 0.0.3.255 host 157.141.29.28
    32 permit tcp 157.141.116.0 0.0.3.255 host 157.141.44.64
    33 permit tcp 157.141.116.0 0.0.3.255 host 157.141.51.111
    35 permit tcp 157.141.116.0 0.0.3.255 host 157.141.138.40
    37 permit tcp 157.141.116.0 0.0.3.255 host 157.141.245.10
    38 permit tcp 157.141.116.0 0.0.3.255 host 157.141.252.13
    39 permit tcp 157.141.116.0 0.0.3.255 host 157.141.252.16
    40 permit tcp 157.141.116.0 0.0.3.255 host 157.141.252.53
    98 permit udp any any eq domain (3 matches)
    99 permit tcp any any eq domain
    100 deny ip any any log-input (169701 matches)

I can ping with sources in that subnet to the dns address. I sourced from the gateway and tried it from two user machines via RDP, but currently the ACL is not applied (so i will test shortly with it applied once the users have left for the day). It was removed as to not impact currently.

Here are some of the hits:

 %SEC-6-IPACCESSLOGP: list IN denied udp 157.141.116.91(51220) (Vlan116 0061.0085.0400) -> 157.141.245.10(53), 1 packet 

 %SEC-6-IPACCESSLOGP: list IN denied udp 157.141.116.89(62439) (Vlan116 0047.006b.0400) -> 157.141.245.10(53), 1 packet

[MHM Cisco World]

sorry I dont get so ACL work or not ?

MHM

[Richard Burts]

Thank you for the output that I asked for. It is quite puzzling, especially the output of the denied packets. 

%SEC-6-IPACCESSLOGP: list IN denied udp 157.141.116.91(51220) (Vlan116 0061.0085.0400) -> 157.141.245.10(53), 1 packet

There are 2 entries in the ACL that should have permitted this packet, but it was denied. So we are missing something. Would you post the configuration of the interface?

[MHM Cisco World]

Friend use log you get to know source IP and destiantion and l4 udp port.

Add these inform into new ACL above deny ip any any log and your issue will solve

MHM