Our ISP is blocking the NTP Protocol. No matter what NTP server we put it doesn’t update the time.
So I thought of Installing a Mikrotik router with NTP server enabled elsewhere in the world with Public iP and then from the client Mikrotik I can establish a VPN connection to the Mikrotik with NTP server and update the time of the client MIkrotik.
Can you guide me on how to do it? My client Mikrotik has simple configuration 1 WAN and 1 LAN.
Have you simply ask your ISP if is really blocked and what time server you must use?
Have you check if the problem is not the client?
Have you check if the problem is your settings on devices?
Come on guys! It is “quite common” that an ISP blocks all traffic from UDP port 123, because they have been confronted with clients running old/unpatched/wrongly configured NTP servers and these have been used for DDoS attacks. Don’t act as if this is impossible or silly.
Usually they block only port 123 on the client side and it is possible to get NTP service from others by doing a src-nat that translates port 123 to something else (e.g. 12300).
So your NTP requests will go out as your_address:12300 → server_address:123 and these are not blocked.
To do this you can add a rule like this:
Got numbers? The only time I’ve seen that is in pocket IT dictatorships, not among general-service ISPs.
There’s far too much dependence on clients being able to get Internet time syncs to block it wholesale. Just to pick an example, the Raspberry Pi boards don’t even have a real-time clock on board, to save BoM cost. They figure if you need accurate time, you can hook it up to a network easily enough.
a src-nat that translates port 123 to something else (e.g. 12300)
I tested my local machine (macOS 12) and it does as you say: uses 123 for the UDP source port as well as the destination. I would have thought the source port would be random, being a client packet.
If it works, that’s a nice fix. Too bad it’s a fix for a heavy-handed policy, but nice fix anyway.
Sure there are other ways to filter it, but as a user you will have to cope with what the ISP has decided to do, and with many ISP’s there is no discussion forum to chat about the validity of the operator’s decisions. So working around them is the only viable alternative.
I have experienced such a block personally. At first I did not understand at all what was happening, because some systems could do NTP and others could not, and it turned out to be indeed related to the source port they use. Sometimes a “random source port” is used (especially when it is really SNTP what they are doing) and it works just fine, sometimes the source port is always 123 and it fails. But with that workaround it was solved. I should say the rule was manually constructed from memory as that particular installation has changed to another network and this config is not present anymore. But I think that is what I used.
Edit: now I realize that there is at least one thing missing from that rule above: it should include some form of direction matching, e.g. by using an out-interface or out-interface list, or else the replies from the NTP servers (which have source port 123 too) will be translated.
If you were asking why I would buy something, I had unrelated reasons that I desired a local NTP server (stuff that had no internet connection at all).
Because the linked-to product is a GPS-disciplined clock, so it’s always accurate as long as its antenna can see the sky.
You might set up an NTP client and server on an ROS device to redistribute its time, as with a campus internal router to keep NTP traffic off the shared link to the building where the GPS clock lives.
With such a design, the cheap crystal in the router no longer drifts as it would in the OP’s situation, but at the same time, the GPS clock isn’t carrying the whole load.
Well, that box (and also the LeoNTP that I use) provides time info “by itself” while the RouterOS package can only track other systems that untimately derive from such a source.
The starter of this topic experiences the problem that his NTP traffic is dropped, and so the RouterOS package cannot work unless he can find a workaround for that problem.
But such a standalone GPS clock would still work. Of course the network filter problem gets replaced by a signal filter problem (the antenna has to be placed somewhere where the GPS satellites can be received).
Possibly stupid question, but if you’re buying some extra hardware, is there anything wrong RouterOS “gps” package, cheap USB GPS receiver and then in RouterOS:
If you’re up for another experiment, I suspect you’ll find that any given Routerboard’s RTC (if it has one at all) drifts by something like a few seconds a day unless externally-disciplined.
More reading on that GPS clock page showed another reason to redistribute its time source with RouterOS’s NTP server: 10/100 Ethernet, so it’s liable to be spammed off the network by random broadcast and multicast traffic if you don’t wall it off.
A common scheme is to have the Stratum 1 GPS clock visible to a single rack of equipment at most, then feed everything else from your new Stratum 2 time server, living in that rack, fed by the Stratum 1 clock.
There must be practical limits on the length of the GPS antenna’s coax cable back to the receiver. Parasitic dB losses, interference, etc. Coupled with the short maximum practical length of USB cables, there are buildings where you can’t even get out to a nearby wall with a USB GPS clock.
Or, there may be such a wall in your local situation, but it faces one of those urban canyons where forlorn GPS receivers go to die, so your incentive is to put the antenna near the building’s rooftop to get a clear view of the sky.
With the PoE-powered GPS receiver linked above, you could have a data center in the basement and the antenna on the roof of a high-rise.
Still, it’s good to be reminded of the option for less fraught cases, so thank you.
Uhm, no? ISPs should not, ever, be filtering traffic. Not their responsibility. If my ISP blocks port 123 (or any port for that matter), I’ll be cancelling services very promptly thereafter.
Well, what is at least wrong with that is that it uses the NMEA output strings from the GPS and not the PPS (pulse per second) signal.
That means it is “really inaccurate” (at least 300ms offset, I guess). An NTP server on internet will work much better than that package (and a USB GPS dongle).
There are some devices with built-in GPS function but I think even those do not have PPS support. But I am not sure about that.
A dedicated device like shown above or LeoNTP that I have will maintain time with nanosecond precision and will deliver it over the network with microsecond precision.
Well, what is at least wrong with that is that it uses the NMEA output strings from the GPS and not the PPS (pulse per second) signal.
That means it is “really inaccurate” (at least 300ms offset, I guess). An NTP server on internet will work much better than that package (and a USB GPS dongle).
There are some devices with built-in GPS function but I think even those do not have PPS support. But I am not sure about that.
A dedicated device like shown above or LeoNTP that I have will maintain time with nanosecond precision and will deliver it over the network with microsecond precision.
Hi,
I would say for normal network/server troubleshooting a sub second accuracy is enough, especially if you synchronize everything from the same source.
No you shouldn´t advertise that on the Internet as your public stratum 1 server and if you are an enterprise you should probably buy at least two Meinbergs (~10k).
If not, here is a link for any Openwrt capable cheap router: https://openwrt.org/docs/guide-user/services/ntp/gps, but the Mikrotik gps support would be probably fine as well.
Happens all the time. I see you’re in SA like me. My ISP is ClearAccess, and they even block ssh (tcp port 22), telnet (tcp port 23) and winbox (tcp 8291).. Whether it’s just badly implemented rules intended for transit infrastructure somehow affecting me as a client, is irrelevant I guess. Point is, I can’t use those ports, they’re blocked on the WAN side even if my firewall is open.
Fortunately that’s not a problem, as those ports shouldn’t be open on wan side anyway. VPN bypass does the trick
Lots of ISP’s also redirect port 25. So this type of thing is not new. If that’s enough to make you cancel your service you may have a hard time finding service depending where you live, lol