ntp-client status waiting

RouterOS Beginner Basics
1

I have an RB3011 (router), a hAP ac lite (bridge) and a cAP (bridge). On the two Mikrotik devices configured as bridge the ntp-client is updated correctly however on the router the status remains ‘waiting’.
All devices have the same RouterOS versin (7.2.3) and all three devices work, with exeption of the ntp-client, as expected.
An export of the /system/ntp/client shows:

/system ntp client
set enabled=yes
/system ntp client servers
add address=0.pool.ntp.org
add address=1.pool.ntp.org
add address=2.pool.ntp.org
add address=3.pool.ntp.org

The debug logs show the following.

16:35:31 echo: ntp,debug TMP: Start resolving name: 0.nl.pool.ntp.org
16:35:31 echo: ntp,debug TMP: Start resolving name: 1.nl.pool.ntp.org
16:35:31 echo: ntp,debug TMP: Start resolving name: 2.nl.pool.ntp.org
16:35:31 echo: ntp,debug TMP: Start resolving name: 3.nl.pool.ntp.org

16:35:31 echo: ntp,debug TMP: Resolved address: 0.nl.pool.ntp.org -> 162.159.200.1
16:35:31 echo: ntp,debug TMP: Resolved address: 1.nl.pool.ntp.org -> 212.114.109.139
16:35:31 echo: ntp,debug TMP: Resolved address: 2.nl.pool.ntp.org -> 94.198.159.15
16:35:32 echo: ntp,debug TMP: Resolved address: 3.nl.pool.ntp.org -> 40.119.148.38

16:35:32 echo: ntp,debug TMP: Unreachable and iburst enabled. Send burst
16:35:32 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:32 echo: ntp,debug TMP: Unreachable and iburst enabled. Send burst
16:35:32 echo: ntp,debug TMP: tx dst-ip:212.114.109.139

16:35:33 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:33 echo: ntp,debug TMP: tx dst-ip:212.114.109.139

16:35:34 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:34 echo: ntp,debug TMP: tx dst-ip:212.114.109.139

16:35:35 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:35 echo: ntp,debug TMP: tx dst-ip:212.114.109.139

16:35:36 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:36 echo: ntp,debug TMP: tx dst-ip:212.114.109.139
16:35:36 echo: ntp,debug TMP: Unreachable and iburst enabled. Send burst
16:35:36 echo: ntp,debug TMP: tx dst-ip:94.198.159.15

16:35:37 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:37 echo: ntp,debug TMP: tx dst-ip:212.114.109.139
16:35:37 echo: ntp,debug TMP: Unreachable and iburst enabled. Send burst
16:35:37 echo: ntp,debug TMP: tx dst-ip:40.119.148.38

16:35:38 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:38 echo: ntp,debug TMP: tx dst-ip:212.114.109.139
16:35:38 echo: ntp,debug TMP: tx dst-ip:94.198.159.15

16:35:39 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:39 echo: ntp,debug TMP: tx dst-ip:212.114.109.139
16:35:39 echo: ntp,debug TMP: tx dst-ip:40.119.148.38

16:35:40 echo: ntp,debug TMP: tx dst-ip:162.159.200.1
16:35:40 echo: ntp,debug TMP: tx dst-ip:212.114.109.139
16:35:40 echo: ntp,debug TMP: tx dst-ip:94.198.159.15

16:35:41 echo: ntp,debug TMP: tx dst-ip:40.119.148.38

16:35:42 echo: ntp,debug TMP: tx dst-ip:94.198.159.15

16:35:43 echo: ntp,debug TMP: tx dst-ip:40.119.148.38

16:35:44 echo: ntp,debug TMP: tx dst-ip:94.198.159.15

Why do I not receive any replies.

2

Are there devices all at the same location - or more important, using the same internet? Recently someone else here on the forum had their ISP blocking NTP traffic.

3

Try turning the NTP client off (uncheck Enabled), Hit Ok, then go back and turn it back on…

I had this recently on one of mine and that fixed it.

4

Did not solve it, neither as rebooting the device…

5

Yep, all are at the same locations and using the same internet. The RB3011 is behind the ISP router where the RB3011 is (currently) set as DMZ.

6

It could be that the ISP blocks packets with source port 123, and thus the router which sends direct untranslated queries won’t get replies.
The other two devices are behind NAT, their port number is translated by the NAT, and they get replies.
It is becoming more or less common to block source port 123 to prevent clients from running NTP servers.

7

OK, interesting! Would it be possible to NAT the request to the ntp-server from the router internally?

8

Yes. Try that, it should work. When it solves the problem, it is an ISP filter.
Of course you can also (at least with v7) specify the different devices mutually as servers. Then at least you have time sync while you are trying to solve the issue.

9

OK, recollecting, my router with RouterOS 7.2 could not update the date/time information from NTP servers. Some tests (ping/traceroute) revealed that the IP addresses of the NTP servers were actually resolved but UDP port 123 was blocked, probably by my ISP. Searching and collating some of the forum posts on NTP lead me to the following firewall rule. This solved the problem.

/ip firewall nat
add action=masquerade chain=srcnat comment="NTP NAT masquerade " dst-port=123 protocol=udp to-ports=12300-12390

The ports (12300-12390) can be changed ad lib. It does not matter very much where you put this rule in the NAT-records, but if it does not work out of the box you may need to move it upward. After disabling/enabling the NTP-client, in just a few seconds the time settings are synchronised, of course under the condition that you entered some valid NTP-servers (like 0.pool.ntp.org, …)

Thanks all for your help!

10

Ok it would be advisable to also include an out-interface matcher e.g. out-interface-list=WAN (assuming you have that list and your internet interface is in it).

11

Thank you very much, it works

12

Great!!!

I had this problem for a while and with this it is solved.

Thank you!!!


13

It has been discussed in other topics as well, after some denial the users install such a NAT rule and all starts working.
(even after the ISP has claimed “they do not filter”)

Of course it would be best when MikroTik added a new option to NTP client: use random source port number (instead of 123)…

14

I just had an issue where I could not get NTP. Device is Router behind NAT, but other Units in the setup could get NTP.

Confirmed Firewall - no specific Blocks or allows, but allow Established / Allow Related Forward on Outer Router, and Allow Established on Inner “problem” router.

Checked other, appear to be all the same, however as I had not personnaly configured these, and the boss just kinda when ham, there was a few pickles in the mix, why I was in there in the first place.

For NTP, somewhere along the line the mode got changed to 'broadcast", and as my “repair” config being dropped on to was based on my defult config, and default mode is “unicast”, i did not have this explicit as part of the script.

Just dropping for anyone who might have come across this thread with a similar problem.

15

Ok that of course is a mistake… by default it is set to unicast.
You can get it to work with “broadcast” as well, by setting the “broadcast” flag on the server side.
It is less secure. When the devices are on a network where everyone can plug in devices and start doing broadcasts, someone who wants to have some fun could broadcast wrong time.