NTP ACL not working

[the-lebowski]

Can someone please help me figure out why NTP is not being allowed when this ACL is applied inbound on the internet facing interface?  everything else works but NTP broke and not sure why.  

 interface GigabitEthernet0/0/0
 ip address 1.2.3.4 6.7.8.9
 ip nat outside
 ip access-group NTP-ACL in
 negotiation auto
.....
    209 permit udp any any eq ntp log (1 match)
    210 permit udp any eq ntp any eq ntp log (2 matches)
.........
show ntp associations

  address         ref clock       st   when   poll reach  delay  offset   disp
*~128.199.169.185 199.101.96.52    3     48     64     7  2.951 -69.055 189.17
 * sys.peer, # selected, + candidate, - outlyer, x falseticker, ~ configured

show ntp status
Clock is unsynchronized, stratum 4, reference is 128.199.169.185
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**10
ntp uptime is 95500 (1/100 of seconds), resolution is 4000
reference time is ECAA2739.824DD458 (01:15:37.509 SGT Tue Oct 28 2025)
clock offset is -75.3579 msec, root delay is 251.09 msec
root dispersion is 145.57 msec, peer dispersion is 1.90 msec
loopfilter state is 'FREQ' (Drift being measured), drift is 0.000000000 s/s
system poll interval is 64, last update was 62 sec ago.

[M02@rt37 · Accepted solution]

Hello @the-lebowski 

Add a rule above those two to explicitly permit replies from NTP servers:

access-list NTP-ACL permit udp any eq ntp any

[the-lebowski]

Added and appears to be working now but not clear why I needed that statement as well?

show ntp status
Clock is synchronized, stratum 5, reference is 128.199.169.185
nominal freq is 250.0000 Hz, actual freq is 250.0113 Hz, precision is 2**10

    209 permit udp any eq ntp any (122 matches)
    210 permit udp any any eq ntp log
    211 permit udp any eq ntp any eq ntp log

[M02@rt37]

@the-lebowski 

Your router sends packets to port 123__ already allowed. The NTP server replies from port 123__ was blocked before added this statment.

[balaji.bandi]

Is this NTP request going out or coming in from the internet?

Have you tried the other way around?

interface GigabitEthernet0/0/0
 IP access-group NTP-ACL out

another thing you are doing, NAT, can you post the complete configuration?

Is the NTP configuration on the same device where you are doing NAT?

may some correction example

permit udp 10.10.10.10 any eq 123
permit udp any eq 123 10.10.10.10 

[Joseph W. Doherty]

Possibly 

permit udp any eq ntp any log

Edit: I now see M02@rt37 already had that.

Your other two ACEs shouldn't be needed for return.

You can further tighten the above ACE by using NTP server IP(s).

You might also consider using a reflexive ACLs.

[the-lebowski]

@Joseph W. Doherty  Can you give me an example?  What is odd is that nothing changed and that ACL is in use across our environment all using some form of NTP or another but it only broke here which is odd.  I don't want to limit to a specific server because it would require those ACLs get updated anytime it changes and I don't want that.  I basically want to allow outbound NTP and then only allow replies to those outbound requests.

[Joseph W. Doherty]

---

@the-lebowski wrote:

@Joseph W. Doherty  Can you give me an example? 

---

An example of?  Reflexive ACLs?  If so, Cisco documentation likely better . . .

https://www.cisco.com/c/en/us/support/docs/security/ios-firewall/23602-confaccesslists.html#toc-hId--466955766

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-10/configuration_guide/sec/b_1710_sec_9500_cg/m9-1710-sec-reflexive-access-lists-.html

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_acl/configuration/15-mt/sec-data-acl-15-mt-book/sec-cfg-ip-filter.html

BTW, my browser's AI summary describes:

Reflexive access control lists (ACLs) on Cisco devices are designed to enhance network security by dynamically filtering traffic based on the state of a session, making them particularly effective in conjunction with Network Address Translation (NAT).
They function as a form of stateful inspection, tracking outbound connections and automatically allowing return traffic, which simplifies the configuration of access rules compared to static ACLs.  This capability is especially useful in NAT environments, where internal IP addresses are hidden from external networks, as reflexive ACLs can maintain session state across NAT boundaries.

To implement reflexive ACLs with NAT, an extended named ACL is used to define outbound traffic that should be tracked. For example, an ACL can be configured to permit TCP and UDP traffic with the reflect keyword, which creates a dynamic reflexive entry for return traffic.  This reflexive entry is then evaluated by an inbound ACL using the evaluate command, ensuring that only legitimate responses to initiated sessions are permitted back into the network.  This approach allows the router to dynamically create temporary entries in a reflexive ACL based on outbound traffic, which are later used to validate inbound packets.

Reflexive ACLs are compatible with NAT and are best suited for environments requiring dynamic filtering based on session state, such as those using NAT to conceal internal IP addresses or enforcing strict security policies.  They can be used alongside other static ACLs and are configured using extended named IP ACLs; they cannot be defined with numbered or standard named ACLs.
The configuration involves creating an outbound ACL with permit statements that include the reflect keyword to generate reflexive entries, and an inbound ACL that uses the evaluate command to reference these entries for return traffic validation.

[Joseph W. Doherty]

---

@Joseph W. Doherty wrote:

Your other two ACEs shouldn't be needed for return.

---

If you're wondering about the above:

209 permit udp any any eq ntp log (1 match)
210 permit udp any eq ntp any eq ntp log (2 matches)

As the ACL is applied "in", ACE 209 is matching the NTP port as a destination.

ACE 210 is matching NTP port for both server and requesting host. 

From what I read, the host might use a different port number than 123.

So, both of these ACEs might fail if the host, i.e. the destination port number, isn't using port 123.

However, the server side would be usually expected to always use port 123.  Which is why

permit udp any eq ntp any (122 matches)

appears to be working.  I.e. NTP server port, source for return, is 123, while host port is any.

BTW, a reflexive ACL would be more secure, because the return NTP packet needs to "mirror" what was sent to the NTP server.  I.e. the return packets needs to match expected IPs and ports.