I have 20+ Mikrotik routers in the field at client locations. These are mostly RB750s, but there are also some CCRs. At some point in 2016 the SNTP stop adjusting the clocks on all of these routers. I’ve tried firmwares from 6.12 to 6.38, with the same results. I see the NTP request go out, but nothing is coming back. None of these router are behind firewalls; they are all connect either to fiber ONTs or bridged modems directly from the ISP.
I do have one CCR1016 behind a SonicWall that is working. It’s the only one I have that the SNTP is working.
For what it’s worth, I do not get a ping response from us.pool.ntp.org, but I do get a ping response from both IPs you listed. I’m trying this from a PC in southern California, USA.
I looked at both of my RB750s and I have 50.22.155.163 and 131.107.13.100, and no DNS name. Both show the active server to be the 50.22.155.163 address. I sort of recall that the DNS did not work for me either, which is why I just grabbed a couple of IPs that did. I don’t remember if these are from ntp.org or NIST, or something else.
To answer a few questions:
-I’m using the default SNTP that comes with the routers
-From the router I can ping us.pool.ntp.org. It resolves to different addresses each time (Which is how I understand that address to work)
-with that and other testing, I believe DNS is functioning properly.
-I just tried using 50.22.155.163 & 131.107.13.100 without a DNS name, as suggested, with the same results.
-Using the program NetTime, I can use us.pool.ntp.org or any of the addresses listed and get NetTime to work
The kicker is that it used to work. It worked fine for years, but something has changed in the past year. I’ve contact my ISP and they claim they don’t block anything, but I’m not fully convinced of that yet either.
The issue usually is that the ISP starts blocking outbound traffic with a source port number 123.
When you take a SNTP client that sends requests from a random port number to the server (destination port 123)
you get replies, but when you use both source and destination port 123 as an NTP server does, it fails.
Providers sometimes do this to prevent clients from running NTP servers, as they have experienced
that badly maintained NTP servers can cause DDoS and router/firewall overload issues.
I did have a problem with NTP that my ISP sends me a NTP server with ip 1.2.3.4
This is not a valid IP and a bug in RouterOS makes SNTP and NTP stops working if the server it get from DHCP does not work.
Even if I add server manually it does not work.
So to get it to work I needed to got to IP->DHCP Client->Select client->remove check mark from Use Peer NTP.
Solved! It was my ISP. They got back to me that they were blocking NTP:
We were blocking incoming NTP, thinking that it would still allow NTP to work from our network to the outside world, but not allow random NTP requests back in. This was due to problems with NTP related DDOS attacks we had received.
I had them allow NTP incoming NTP and all my routers starting pulling NTP adjustments. Thanks for all the replies.
A case could be made that the SNTP service should not use 123 as source port number, only the NTP service should do so.
That way, when you do not run an NTP server yourself and only want to sync to outside servers, you have less risk the requests or replies are blocked.
SNTP can use a random high source port number, and many clients do so.
if you are using pool.ntp.org NTP servers you HAVE to use the domain name, or you have to frequently resolve the domain name. Ntp.org is doing automatic adjustment of the clients and you can be allocated to a different server with a different address and they will just stop answering to your queries.
Not really. There is a pool of servers, and the DNS gives you a few of them that it recently has validated.
Such a server can disappear at any time (e.g. because the ISP implements the above filtering rule or the user who runs it discovers that it can lead to nasty problems in routers doing connection tracking), and then there will no longer be answers. When you would resolve DNS again, you get another server which still works at that time.
But there is no allocation of clients to servers and automatic stop serving clients that do not resolve the DNS often enough.
at least with local Latvian pool NTP servers that is the case as same servers are here for years. When I try to get the address - the pool responds with some address, and i specifically know what server is that. After 4 to 8 weeks same domain will give me a different address. No other of the active servers will respond to the NTP requests just the one returned when resolving domain name. After some time my device can be slotted back and that happens as NTP pool load balances the requests over available servers.
It must be perception only. There is nothing the NTP pool do or can do to track its users in relation to its servers!
The NTP pool is “just” a table of available servers and a clever DNS server to hand out the suggested servers to
use at that time. There is no bookkeeping what servers were given to whom, and it would not be possible to do so
because there may be provider DNS resolvers inbetween that send the same answer to several clients.
And this info certainly is not shared with the servers, I know that because I operate one of those servers.
The server operator can check the pool.ntp.org website to see what the pool’s opinion of his server is (if it is
considered a valid server and thus is in the list that the DNS server hands out), but there is no way to retrieve a
list of clients that have been given the server’s address.
In my test case, I have hAP ac2 as the main router and in the LAN connected the second hAP ac2 as the VPN server. I cannot understand why, when the hAP(from LAN) sends a request to the NTP server on the Internet and the NAT of the main router not change the source port (123) to any??? That’s why I had to use masquerading…
Strictly speaking, if some port on router’s WAN interface is not already used for existing connection to the same remote address, then NAT process does not have to change src-port (connection tracking engine only needs to track the tuple protocol/src-address/src-port/NAT-address/NAT-port/dst-address/dst-port and keep its last 4 parts a unique combination for each connection).
If your main router was running NTP service on default port (UDP/123), then NAT would probably change src-port for every out-going connection to make sure that it is not interfering with NTP server running on main router. When main router doesn’t run NTP server (or at least it’s not listening on WAN interface), then changing src-port for the first LAN host contacting same public NTP Server is not needed for this reason (but if there’s another reason for doing it, you have to do it manually) - if another LAN host would contact the same public NTP server, NAT would have to change src-port.
