Hello everyone,
I have a problem with the NTP client on my Mikrotik, and I know this topic has been discussed several times.
To the point: the IPS provider is blocking any traffic on UDP port 123.
I have a NAS server and several other devices behind the Mikrotik, which uses a NTP client with the NTP server pool.ntp.org (for ex.).
All of them are syncing the time correctly. When it’s working on this devices, why can’t my Mikrotic sync it?
Thanks in advance for your help 
Check first thing that the NTP server address is resolved correctly.
I.e. in terminal try running:
put [:resolve pool.ntp.org]
and:
put [:resolve domain-name=pool.ntp.org server=8.8.8.8]
The first command will use your currently configured DNS, the second will use the google one at 8.8.8.8 (change it if needed).
I tried it with couple ntp servers - the IP address is resolved correctly for my current DNS and for the google one.
Without seeing MT NTP config and input chain firewall rules config, hard to make any assessment.
Then likely the issue is connected with your router (firewall or whatever) settings. (If other devices have NTP working it cannot be the ISP blocking port 123 or similar).
Post your configuration, follow these instructions:
http://forum.mikrotik.com/t/forum-rules/173010/1
When you already know the problem is that your ISP filters port 123, it should not be difficult to find the well known workaround for that here on the forum…
(add a NAT rule that translates the source port for outgoing NAT requests to something else than 123)
Sure it would be convenient when there was some option in the NTP client to use a random source port number instead of 123, but there isn’t.
My ISP blocks inbound UDP packets on port 123 on both IPv4 and IPv6 too (with the exception of a few whitelisted IPv4 addresses from a national NTP service - ntp.br).
RouterOS’ NTP client as well as Windows’ NTP client both use the source port 123 when performing their NTP requests. With that, the response from the server comes with the destination port 123 and gets blocked by my ISP.
To work around that, I’ve simply created two source NAT rules (one for IPv4 and one for IPv6) to change the source ports of the requests to ones on the dynamic/ephemeral range.
IPv4 rule (must come before the all-encompassing source NAT or masquerade rule):
/ip firewall nat add action=masquerade chain=srcnat out-interface-list=wan-interface-list protocol=udp src-port=123 to-ports=49152-65535
IPv6 rule:
/ipv6 firewall nat add action=src-nat chain=srcnat out-interface-list=wan-interface-list protocol=udp src-port=123 to-ports=49152-65535
yuripg1 thank you very much, the first IPv4 rule made the trick, it’s working now 
Also thanks to all other for their involvement.
So all the devices behind the Mikrotik router were already using non-123 ports?
I did not get that the ISP blocking Port 123 was an established fact, my bad.
Happy that the issue was solved.
Can one then conclude that RoS is hardwired to use the standard 123 port for outgoing NTP traffic but NTP servers on the internet will accept any port ???
Yes, RouterOS uses source port 123, by their choice, when the NTP client is performing NTP requests (and so the response comes with destination port 123), but NTP servers don’t care about the source port. Only about the destination port, of course, which must be 123.
Perhaps MikroTik went this way for symmetry and ease of firewalling (by using port 123 both ways). Who knows? Windows also uses source port 123 for some reason (and they are still using NTP v3 - yikes).
NTP uses port 123 for both source and destination port when running in peer-to-peer mode (Mode 1 & 2). ROS probably does it for mode 3 (client-server) as well to keep thing simple.
I think we can say that the Mikrotik is not by default compliant with RFC9109, which is relatively recent:
https://datatracker.ietf.org/doc/html/rfc9109
The following text from Section 9.1 (Peer Process Variables) of [RFC5905]:
dstport:
UDP port number of the client, ordinarily the NTP port number PORT (123) assigned by the IANA. This becomes the source port number in packets sent from this association.is replaced with:
dstport:
UDP port number of the client. In the case of broadcast server mode (5) and symmetric modes (1 and 2), it SHOULD contain the NTP port number PORT (123) assigned by IANA. In the client mode (3), it SHOULD contain a randomized port number, as specified in [RFC6056]. The value in this variable becomes the source port number of packets sent from this association. The randomized port number SHOULD NOT be shared with other associations, to avoid revealing the randomized port to other associations.
Interesting so the Randomized port SourceNAT rule is our work around user method of conforming to the standard while MT sits on their thumbs… eyes glazed over, overdosed on some Latvian candy 