Wired Intelligent Edge

last person joined: 12 hours ago 

Bring performance and reliability to your network with the HPE Aruba Networking Core, Aggregation, and Access layer switches. Discuss the latest features and functionality of your switching devices, and find ways to improve security across your network to bring together a mobile-first solution
Expand all | Collapse all

Weird ACL behavior with NTP on 5412Rzl2

This thread has been viewed 0 times
  • 1.  Weird ACL behavior with NTP on 5412Rzl2

    Posted Jul 09, 2019 10:15 AM

    Hey all - so I ran into a bit of weirdness yesterday with an ACL applied outbound on a VLAN interface on my core 5412Rzl2. The problem was that our DCs were unable to sync their time with our NTP servers. The DCs live in different subnets than the NTP servers. The problem turned out to be with the ACL applied outbound to the VLAN that the NTP servers reside in. However, that same ACL had permits allowing the DCs to the entire subnet for ip. There is also another permit allowing UDP traffic from our internal networks into the subnet where the NTP servers live. There are no rules that would block this traffic before the allows in the ACL that I can see.

     

    Removing the ACL from the VLAN interface resolved the issue, but of course that wasn't a true fix for the situation. I ended up having to add specific permits from the DCs to the NTP servers for udp/123 before the DCs could sync their time with the NTP servers. Given the other ACEs already in place I am not sure why this was necessary.

     

    Below is the relevant portion of the outbound ACL in question. IPs have been changed to santize the ACL for a public forum. Also, a couple SNMP allow rules have been omitted for brevity. The ACL is actually much longer than what is presented here, but the rest isn't needed for troubleshooting this issue. Please note: This is the ACL after the specific NTP allows have been added. 

     

       remark "deny WiFi networks"
       deny ip 10.100.0.0 0.0.31.255 192.168.246.0 0.0.0.255
       deny ip 10.103.0.0 0.0.31.255 192.168.246.0 0.0.0.255
       remark "deny ping to broadcast"
       deny icmp 0.0.0.0 255.255.255.255 192.168.246.255 0.0.0.0 log
       remark "allow ping from internal networks"
       permit icmp 10.0.0.0 0.255.255.255 192.168.246.0 0.0.0.255
       permit icmp 192.168.240.0 0.0.7.255 192.168.246.0 0.0.0.255
       permit icmp 192.168.248.0 0.0.0.255 192.168.246.0 0.0.0.255
       remark "allow NTP from DCs to NTP servers"
       permit udp 192.168.240.15 0.0.0.0 192.168.246.50 0.0.0.0 eq 123
       permit udp 192.168.240.15 0.0.0.0 192.168.246.101 0.0.0.0 eq 123
       permit udp 192.168.240.15 0.0.0.0 192.168.246.130 0.0.0.0 eq 123
       permit udp 192.168.240.16 0.0.0.0 192.168.246.50 0.0.0.0 eq 123
       permit udp 192.168.240.16 0.0.0.0 192.168.246.101 0.0.0.0 eq 123
       permit udp 192.168.240.16 0.0.0.0 192.168.246.130 0.0.0.0 eq 123
       permit udp 192.168.240.17 0.0.0.0 192.168.246.50 0.0.0.0 eq 123
       permit udp 192.168.240.17 0.0.0.0 192.168.246.101 0.0.0.0 eq 123
       permit udp 192.168.240.17 0.0.0.0 192.168.246.130 0.0.0.0 eq 123
       permit udp 192.168.248.12 0.0.0.0 192.168.246.50 0.0.0.0 eq 123
       permit udp 192.168.248.12 0.0.0.0 192.168.246.101 0.0.0.0 eq 123
       permit udp 192.168.248.12 0.0.0.0 192.168.246.130 0.0.0.0 eq 123
       permit udp 192.168.248.13 0.0.0.0 192.168.246.50 0.0.0.0 eq 123
       permit udp 192.168.248.13 0.0.0.0 192.168.246.101 0.0.0.0 eq 123
       permit udp 192.168.248.13 0.0.0.0 192.168.246.130 0.0.0.0 eq 123
       permit udp 192.168.248.14 0.0.0.0 192.168.246.50 0.0.0.0 eq 123
       permit udp 192.168.248.14 0.0.0.0 192.168.246.101 0.0.0.0 eq 123
       permit udp 192.168.248.14 0.0.0.0 192.168.246.130 0.0.0.0 eq 123
       remark "allow all traffic from Domain Controllers"
       permit ip 192.168.240.15 0.0.0.0 192.168.246.0 0.0.0.255
       permit ip 192.168.240.16 0.0.0.0 192.168.246.0 0.0.0.255
       permit ip 192.168.240.17 0.0.0.0 192.168.246.0 0.0.0.255
       permit ip 192.168.248.12 0.0.0.0 192.168.246.0 0.0.0.255
       permit ip 192.168.248.13 0.0.0.0 192.168.246.0 0.0.0.255
       permit ip 192.168.248.14 0.0.0.0 192.168.246.0 0.0.0.255
       remark "Allow DMZ to Server Subnet unrestricted"
       permit ip 192.168.241.0 0.0.0.127 192.168.246.0 0.0.0.255 log
       remark "allow SNMP on Netsight-Server for management network"
       permit udp 172.18.0.0 0.0.255.255 192.168.246.150 0.0.0.0 range 161 162
       remark "block SNMP from other networks"
       deny udp 0.0.0.0 255.255.255.255 192.168.246.0 0.0.0.255 range 161 162 log
       remark "allow UDP from internal networks"
       permit udp 10.0.0.0 0.255.255.255 192.168.246.0 0.0.0.255
       permit udp 192.168.240.0 0.0.7.255 192.168.246.0 0.0.0.255
       permit udp 192.168.248.0 0.0.0.255 192.168.246.0 0.0.0.255
       permit udp 172.18.0.0 0.0.255.255 192.168.246.0 0.0.0.255

    The 5412Rzl2 is running KB.16.08.0001. Thanks in advance for any feedback.

     



  • 2.  RE: Weird ACL behavior with NTP on 5412Rzl2

    Posted Aug 05, 2019 04:34 PM

    Hi.  Wondering if you resolved this?

    I have a somewhat similar issue...it seems that even though you apply an extended ACL and specify the TCP/UDP port number you want...it just ignores that and blocks all traffic until you issue a "permit ip" to allow anything from that address through.

    It also seems there's no way to apply a reciprocal ACL to filter traffic coming back in...  I've used "permit tcp gt 1023" and "permit udp gt 1023" and it just blocks everything...until I again issue "permit ip".

    We need to filter, and allow, specific ports between our VLAN's but these ACL's are just not working the way I would expect them to.

    I have 5412's on KB.16.08.0002...   -Rob