Correct system time is important, especially when you’re using encrypted network protocols (e.g. TLS, wireguard). On my mikrotik router, I enabled the NTP client with the europe.pool.ntp.org server in System > NTP Client, and waited for the updated system time. And waited. And nothing happened; I couldn’t even find a command to kick it to update the time on the official NTP (SNTP Client) page.

The sntp client on macos worked fine with the same server:

1
2

$ sntp europe.pool.ntp.org
+0.101370 +/- 0.049848 europe.pool.ntp.org 185.177.151.86

I tried using the Packet Sniffer (in Tools) to see the packets for UDP port 123 and saw only transmitted (tx) packets. Then I noticed that the both the destination and source ports were 123 — it kind of makes sense, but it’s unusual because the client’s OS typically picks a random source port to establish a connection. In this case, my ISP is apparently blocking all incoming traffic on port 123 (NTP), that’s why the NTP client doesn’t work.

Then I was able to find this thread: Does RouterOS block NTP traffic by default?, which discusses this issue. Based on a command there, I added a new srcnat rule to change the source port for NTP to a random number:

1
2
3
4
5
6

[user@router] > /ip/firewall/nat/add chain=srcnat action=masquerade to-ports=12400-12440 protocol=udp src-port=123 comment="fix the ntp client by changing its source port 123 with something higher (mikrotik forum 794718)" place-before=0

[user@router] > /ip/firewall/nat/print
Flags: X - disabled, I - invalid; D - dynamic
 0    ;;; fix the ntp client by changing its source port 123 with something higher (mikrotik forum 794718)
      chain=srcnat action=masquerade to-ports=12400-12440 protocol=udp src-port=123

With this rule, the NTP client works great. You can use /ip/firewall/nat/print stats or open IP > Firewall > NAT in WinBox to see the increasing number of handled packets.