NTP protocol Is Blocked by ISP

papayeya · Thu Apr 28, 2022 4:02 am

Dear Members,

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.

Or any other workaround I will appreciate it.

BR

Ahmed Musa

rextended · Thu Apr 28, 2022 12:49 pm

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?

Thu Apr 28, 2022 1:57 pm

Our ISP is blocking the NTP Protocol. No matter what NTP server we put it doesn't update the time.

Non sequitur. It may be that your ISP is passing NTP, and your time isn't updating instantaneously. Why? Because REASONS.

Use an NTP diagnostic program like this one to find out if you're right to blame the ISP in the first place.

pe1chl · Thu Apr 28, 2022 4:28 pm

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:

/ip firewall nat
add action=src-nat chain=srcnat protocol=udp src-port=123 to-ports=12300

and see if there is any difference.
If not, the blocking may be more complicated and a VPN may be required. Or a talk to the ISP.

anav · Thu Apr 28, 2022 4:34 pm

Nice pelchi, nice fix if that is the problem!!

Thu Apr 28, 2022 5:29 pm

It is "quite common" that an ISP blocks all traffic from UDP port 123

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.

clients running old/unpatched/wrongly configured NTP servers

The ISP's firewall should filter based on the protocol mode flag to distinguish client request packets from server replies.

these have been used for DDoS attacks

There are better ways to mitigate an NTP amplification attack than outright blocking.

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.

pe1chl · Thu Apr 28, 2022 6:31 pm

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.

So try something like:

/ip firewall nat
add action=src-nat chain=srcnat out-interface-list=WAN protocol=udp src-port=123 to-ports=12300

(assuming your list WAN correctly includes your internet interface)

k6ccc · Thu Apr 28, 2022 9:18 pm

Another solution is to put your own NTP server inside your LAN and point to that. they are getting inexpensive enough... I recently did that and it is working great. The one I bought is:
https://www.amazon.com/dp/B09FKPY5NS?ps ... ct_details
or of you prefer not to deal with Amazon, https://centerclick.com/ntp/

rextended · Thu Apr 28, 2022 11:56 pm

Why buy something instead of use the NTP package also available on RouterOS???

k6ccc · Fri Apr 29, 2022 12:21 am

Why buy something instead of use the NTP package also available on RouterOS???

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).

Fri Apr 29, 2022 12:24 am

Why buy something instead of use the NTP package also available on RouterOS???

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.

pe1chl · Fri Apr 29, 2022 12:25 am

Why buy something instead of use the NTP package also available on RouterOS???

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).

rextended · Fri Apr 29, 2022 12:31 am

>>>Why buy something....

Thanks all for your answers.
They helped me understand what was written previously.

Just tested: NTP Server installed on RouetrOS 6.48.6 do not reply to time requests if internal clock is not synced with external NTP server...

Sob · Fri Apr 29, 2022 12:48 am

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:

/system/gps/set set-system-time=yes

?

Fri Apr 29, 2022 12:49 am

NTP Server installed on RouetrOS 6.48.6 do not reply to time requests if internal clock is not synced with external NTP server...

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.

Fri Apr 29, 2022 3:34 am

is there anything wrong RouterOS "gps" package

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.

savage · Fri Apr 29, 2022 5:22 am

Come on guys! It is "quite common" that an ISP blocks all traffic from UDP port 123

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.

pe1chl · Fri Apr 29, 2022 10:13 am

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:
Code: Select all
/system/gps/set set-system-time=yes
?

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.

woland · Fri Apr 29, 2022 12:25 pm

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.

W

fragtion · Fri Apr 29, 2022 12:35 pm

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.

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

pe1chl · Fri Apr 29, 2022 1:23 pm

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.

W

The problem is not "MikroTik gps package is bad", but "using a USB GPS dongle as time reference is bad". So those Openwrt packages will perform equally as bad as the gps package.
To solve it, you need one of the specialized NTP server devices shown above. They use PPS sync internally.

woland · Fri Apr 29, 2022 1:47 pm

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.

W
The problem is not "MikroTik gps package is bad", but "using a USB GPS dongle as time reference is bad". So those Openwrt packages will perform equally as bad as the gps package.
To solve it, you need one of the specialized NTP server devices shown above. They use PPS sync internally.

Yes, you are right, both have the same accuracy, which is not as high as it could be with a PPS signal received over GPIO. But the real point is: you don´t _need_ more accuracy for the simple usecase of normal network troubleshooting or setting your laptops clock. Accuracy to the second is mostly OK. And if you are so precise, that you want to compare millisecond timestamps, you can still do it inside your network, which is synchronised from the same, relatively unprecise source.

W

llag · Fri Apr 29, 2022 4:52 pm

The problem is not "MikroTik gps package is bad", but "using a USB GPS dongle as time reference is bad". So those Openwrt packages will perform equally as bad as the gps package.
To solve it, you need one of the specialized NTP server devices shown above. They use PPS sync internally.

An alternative might be to use a raspberry pi with a GPS receiver. That will allow GPS time WITH PPS signal. I have 2 pi's with GPS (one pi 1 and one pi2), works perfectly. Yes it takes some time and effort to set it up.

pe1chl · Fri Apr 29, 2022 5:51 pm

Yeah, but unfortunately (unless you perform more NAT tricks) you cannot enforce that everyone uses your MikroTik as the NTP reference and not some hardcoded or DNS-resolved external server (e.g. time.windows.com) and you will still have a 300ms skew of time inside your network...
Using a Raspberry Pi with dedicated GPS module that has PPS wiring of course is OK. But with current Raspberry Pi availability and prices that dedicated NTP module may be a better choice.

k6ccc · Fri Apr 29, 2022 6:05 pm

woland said:

Accuracy to the second is mostly OK.

Very often true, but sometime annoying. Let me tell you a recent example I dealt with. I was recently in a traffic accident, and I have both a dash camera and driver camera that recorded the accident. I put the two videos together so the driver cam was a Picture in Picture inside the dash cam. Since both cameras have on screen time displays, it was easy to time sync the two cameras - until I watched the result and found that they differed by about 2/3 of a second. I had to time shift one of the videos by watching for activities (a bit of a challenge since the cameras don't have any overlapping video).
The two cameras are able to time sync when they connect to my WiFi at home, but I have no control of how often they do so, or what NTP source they use.

Fri Apr 29, 2022 10:16 pm

A man with a watch always knows what time it is. A man with two watches is never sure.

papayeya · Mon May 02, 2022 7:52 am

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:
Code: Select all
/ip firewall nat
add action=src-nat chain=srcnat protocol=udp src-port=123 to-ports=12300
and see if there is any difference.
If not, the blocking may be more complicated and a VPN may be required. Or a talk to the ISP.

pe1chl,
Thank you for your help.

The ISP confirmed that they are blocking it and they are not going to unblock it. It is blocked for Mikrotik with Private and Public IPs.

When we connected the same Mikrotik to any other ISP the NTP client works without any firewall rule.

Sadly, I tried your rule and It didn't help and still the time is not synced.

Any help on how to do it via VPN?

papayeya · Mon May 02, 2022 7:54 am

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?

Yes confirmed by the ISP they are blocking it form their firewall. The same Mikrotik when we change it to another ISP like 4G, ADSL the NTP client works like charm.

This issue is not for only Mikrotik, this is for any NTP client on any device like routers, hotspot controllers etc.

I think I need to do it via VPN but I don't know how to do it.

Can you help me

pe1chl · Mon May 02, 2022 10:17 am

Did you try the improved rule that was a couple of postings later? The initial try that you quote there was not correct.

papayeya · Mon May 02, 2022 10:16 pm

Did you try the improved rule that was a couple of postings later? The initial try that you quote there was not correct.

My apology. Did you mean you can't see my reply?

Edit: Just figured what you mean. I will try the one with the Output interface list and let you know. Give me a min.

papayeya · Mon May 02, 2022 10:22 pm

I want to thank eveyone who is participating in this post. Very much appreciating your efforts.

It is confirmed that the ISP is blocking NTP protocol and they will not do anything to solve it. I have to do it from my side.
It is not a Mikrotik Issue at all. The same mikrotik router when we plug it to 4G or ADSL or any other provider the NTP client synced like a charm. As soon we connect it to my ISP the NTP client fails to sync.

This is also not a problem specific to Mikrotik. We have several routers like TP-Link Omada OC200 Controller it has the same exact problem.

Not that only in Mikrotik I can't use IP-Cloud login method unless a Public IP is assigned to it. I think they are very strict when it comes to firewall.

Moreover, getting a public IP did not help us to resolve the NTP client issue. So I guess I have to do it by VPN and I need your help to configure it please.

Best Regards

papayeya · Mon May 02, 2022 10:32 pm

Did you try the improved rule that was a couple of postings later? The initial try that you quote there was not correct.

I tried this rule: /ip firewall nat
add action=src-nat chain=srcnat out-interface-list=WAN protocol=udp src-port=123 to-ports=12300

with a Tweak instead of Out-interface-list, I used "Out Interface" and specified the WAN interface. Turned OFF the NTP client and re-enabled it and also It did not work

I mean did not sync although I am pointing to popular NTP protocols like Micorosoft, Google, Ubiquiti etc

Tue May 03, 2022 2:27 am

It is confirmed that the ISP is blocking NTP protocol and they will not do anything to solve it.

If they won't provide a time server of their own to redress the loss of service, I'd select another ISP, if only since the X.509 certificates behind TLS and multiple VPN protocols are time-based. Those being essential Internet services these days, accurate time is ipso facto also an essential Internet service. I'd give them a pass if they chose a better protocol than NTP, but to provide no time sync service at all is inexcusable.

The same mikrotik router when we plug it to 4G or ADSL or any other provider the NTP client synced like a charm.

If any of those other networks are available at the problem location, you could configure the router with both, then route NTP alone to the alternate network. As a bonus, you then have the ability to fail-over to the alternate network when the main one goes down.

I guess I have to do it by VPN and I need your help to configure it please.

The topic is well-covered elsewhere already. There's a whole section on it in the docs. This forum has many guides, and there are third-party sources if you don't like any of those options.

The only element that varies on this point is whether you want to route just NTP to this VPN or send all traffic over it. It's easier to route everything, and it may give service benefits, such as to avoid any other ridiculous restrictions your ISP imposes. There are many guides for doing that.

If you wish to route NTP alone, something like this should work:

/routing table add name=NTP fib
/ip firewall mangle
add action=mark-routing new-routing-mark=NTP chain=output \
dst-port=123 protocol=udp
/ip route
add dst-address=0.0.0.0/0 gateway=wireguard1 table=NTP

That example assumes you've chosen WireGuard, which in turn assumes you're on RouterOS 7, and also that your ridiculous ISP doesn't block that, too. If you're forced to some other VPN type by any of these considerations, modify the gateway parameter to suit.

kevinds · Wed May 04, 2022 12:22 am

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.

Not really... My GNSS antenna has 100 feet of good coax, could easily triple it. Also the serial cable at 9600 or 4800 baud that GPS runs at can be very, very long without issues.

A more DIY approach is a Raspberry Pi and a GNSS receiver, that can be done for under $100 with a well available and frequently updated script that will install and configure it for you.

For the OP, ask your ISP if they have a time-server for you to use (see if it is provided in the DHCP responses), check if the one Windows/Apple uses is blocked too.. That would mess a lot of computers up if the default time server Windows and Apple uses was blocked. It may just be incoming port 123 that is blocked, in that case, run a separate NTP server on your network that NAT automatically changes the incoming port for.

papayeya · Mon May 09, 2022 3:38 am

It is confirmed that the ISP is blocking NTP protocol and they will not do anything to solve it.

If they won't provide a time server of their own to redress the loss of service, I'd select another ISP, if only since the X.509 certificates behind TLS and multiple VPN protocols are time-based. Those being essential Internet services these days, accurate time is ipso facto also an essential Internet service. I'd give them a pass if they chose a better protocol than NTP, but to provide no time sync service at all is inexcusable.

The same mikrotik router when we plug it to 4G or ADSL or any other provider the NTP client synced like a charm.

If any of those other networks are available at the problem location, you could configure the router with both, then route NTP alone to the alternate network. As a bonus, you then have the ability to fail-over to the alternate network when the main one goes down.

I guess I have to do it by VPN and I need your help to configure it please.

The topic is well-covered elsewhere already. There's a whole section on it in the docs. This forum has many guides, and there are third-party sources if you don't like any of those options.

The only element that varies on this point is whether you want to route just NTP to this VPN or send all traffic over it. It's easier to route everything, and it may give service benefits, such as to avoid any other ridiculous restrictions your ISP imposes. There are many guides for doing that.

If you wish to route NTP alone, something like this should work:
Code: Select all
/routing table add name=NTP fib
/ip firewall mangle
add action=mark-routing new-routing-mark=NTP chain=output \
dst-port=123 protocol=udp
/ip route
add dst-address=0.0.0.0/0 gateway=wireguard1 table=NTP
That example assumes you've chosen WireGuard, which in turn assumes you're on RouterOS 7, and also that your ridiculous ISP doesn't block that, too. If you're forced to some other VPN type by any of these considerations, modify the gateway parameter to suit.

The I have created a PPTP VPN server on a remote Mikrotik that has a public IP and connected to a VSAT (Satellite connection) and the NTP client has no issues to get synced.

I have created also a VPN client (PPTP) on the remote Mikrotik with NTP issues and connected it to the Above Mikrotik successfully via PPTP.

When I tried the first line of your commands: /routing table add name=NTP fib it rose an error on "table". Searched the documentations and no luck.

Mon May 09, 2022 3:57 am

When I tried the first line of your commands: /routing table add name=NTP fib it rose an error on "table". Searched the documentations and no luck.

The command is for RouterOS 7. The whole routing infrastructure is changed around relative to v6. (Details)

Jotne · Mon May 09, 2022 8:11 am

It is confirmed that the ISP is blocking NTP protocol and they will not do anything to solve it. I have to do it from my side.

Did you ask your ISP if they have an NTP server you can use?

papayeya · Tue May 10, 2022 1:31 am

When I tried the first line of your commands: /routing table add name=NTP fib it rose an error on "table". Searched the documentations and no luck.

The command is for RouterOS 7. The whole routing infrastructure is changed around relative to v6. (Details)

Apologize, I should have mentioned my OS version it is 6.49.6. It is connected to an external radius server in which it is not compatible with OS7 yet

papayeya · Tue May 10, 2022 1:31 am

It is confirmed that the ISP is blocking NTP protocol and they will not do anything to solve it. I have to do it from my side.
Did you ask your ISP if they have an NTP server you can use?

Yes it is confirmed. they don't have and I have been running after them for weeks now to put a CPU just to work as NTP server.

k6ccc · Tue May 10, 2022 1:39 am

That fits into the crazy department - they don't provide a service that damn near everyone uses, and then block any attempt to use any one of the many available public NTP servers.

rextended · Tue May 10, 2022 1:39 am

Ignoring the accuracy, until humans life is not involved, you can sync routerboard clock routing the IP used as NTP server
(or directly all your LAN IPs used ad NTP server) on a VPN, and using DHCP server for provide NTP service to all your LAN devices...

Tue May 10, 2022 1:47 am

The whole routing infrastructure is changed around relative to v6. (Details)
Apologize, I should have mentioned my OS version it is 6.49.6.

It's not a big deal. Use the reference I linked to translate the commands I gave above back into v6 form. This doesn't rely on v7 specific features. It's a simple static routing setup.

kevinds · Tue May 10, 2022 2:01 am

That fits into the crazy department - they don't provide a service that damn near everyone uses, and then block any attempt to use any one of the many available public NTP servers.

Yeah.. It doesn't make sense...

Which ISP?

If it is true, setting up your own isn't complicated..

mkx · Tue May 10, 2022 9:17 am

Ignoring the accuracy, until humans life is not involved, you can sync routerboard clock routing the IP used as NTP server
(or directly all your LAN IPs used ad NTP server) on a VPN, and using DHCP server for provide NTP service to all your LAN devices...

Not really. Routerboards don't have on-board real-time clocks so after they boot, they're unsynchronized. And need external (NTP!) source to get going. Only after that they can serve as NTP servers (the source can become unavailable).
Which means that one needs another device to serve as (poor accuracy) NTP server ... not sure if a raspberry pi would do (does it have RTC?).

rextended · Tue May 10, 2022 10:11 am

???

... you can sync routerboard clock routing the IP used as NTP server ... on a VPN...

pe1chl · Tue May 10, 2022 10:44 am

Ignoring the accuracy, until humans life is not involved, you can sync routerboard clock routing the IP used as NTP server
(or directly all your LAN IPs used ad NTP server) on a VPN, and using DHCP server for provide NTP service to all your LAN devices...
Not really. Routerboards don't have on-board real-time clocks so after they boot, they're unsynchronized. And need external (NTP!) source to get going. Only after that they can serve as NTP servers (the source can become unavailable).
Which means that one needs another device to serve as (poor accuracy) NTP server ... not sure if a raspberry pi would do (does it have RTC?).

The situation with a Raspberry Pi is exactly the same as with a Routerboard: it does not have a real-time clock, it needs an NTP server to sync to, and after a reboot it will usually revert to some time in the near past (that was saved to the flash during the last run, which it does every now and then).
But it of course is possible to do what is suggested: setup a VPN to some external VPN server where NTP is not blocked, and then run NTP over that VPN.
Either by routing single addresses over the VPN, or by route-marking all NTP traffic to go over the VPN.
I see no issue with that, other than that you need to make sure you use a VPN that does not require correct time to come up (e.g. something using certificates) and that you need to monitor the situation as the VPN is not really visible to the user but can cause failures when it no longer works.

I still think it is very strange that the ISP blocks NTP in both directions (it blocks UDP port 123 both as source and destination port) and does not provide an NTP server within their own network that is exempt from this blocking.
It looks like they do not know what they are doing. I would look for another ISP.

kevinds · Mon May 16, 2022 1:11 am

Which means that one needs another device to serve as (poor accuracy) NTP server ... not sure if a raspberry pi would do (does it have RTC?).

No, but they are simple and cheap to add.. Adding a GNSS module instead of an RTC would provide very accurate time, and could then serve time for the network..

pe1chl · Mon May 16, 2022 11:38 am

No, but they are simple and cheap to add.. Adding a GNSS module instead of an RTC would provide very accurate time, and could then serve time for the network..

You can do the same thing with a MikroTik router that has USB.

Who is online