Unrelated to your core point but your ISP blocks ntp servers? Wtf? Either some part of the story is missing or that ISP is insane, blocking a piece of core internet infrastructure for which there is, I would guess, no reason.

Some ISPs (e.g. AT&T) block outbound traffic from subscribers with source port 123, to mitigate NTP reflection attacks.

Shouldn't necessarily break your NTP client, right? The client's destination port needs to be 123 but the source port can be anything.

But many NTP clients use port 123 as both the destination and source port.

For a while I had a netfilter POSTROUTING rule that would match outbound packets with source port 123 and force translation of the source port to the 60000-65000 range, which had all my NTP clients working again.

Can you please share the iptables rule?

iptables -t nat -I POSTROUTING -p udp -m udp --sport 123 -j MASQUERADE --to-ports 60000-61000

I don't know why I didn't specify the outbound interface but I probably should have (-o $wan_interface), anyway it did the job for a long time.

The breakthrough I needed to get it to work was discovering that --to-ports option, which I'd never used or seen in the wild before facing this problem.

Not OP , but I have seen type of behaviour , ISPs act like corporate firewalls and block everything by default just allow http on 80 and 443 in their consumer plan and try and sell enterprise/higher plans for literally anything else .

Not just that once a ISP was using a single CG-NATed IP for a ton of users, that the IP was constantly getting rate limited with captcha everywhere including Google Search and Cloudflare. They suggested I buy a plan with dedicated static IP instead of rotating a few more in their routers.

NTP is commonly used for DDoS amplitication.

The right way to do this is to police, not block, and by length.

I want to give mine too, because I really appreciate how well it works for me. I built a Chrome extension and it runs fine on Firefox with 0 changes since Firefox supports the exact same browser APIs. When I was developing with Chrome, I had to manually upload my extension each time I updated it. web-ext reloads the browser for me automatically - you do have to take care to avoid duplicating the DOM since it doesn't reload the tab. Not sure why system time is so critical but it seems like a reasonable expectation.

I mean, the browser apis are close (and Mozilla still has much better documentation) but there are a LOT of edges cases where behavior diverges.

Frankly - I'm a little peeved that Optional permissions in Firefox are STILL broken - The prompt can only be triggered in response to a user action, and Firefox blows the fuck up if you put a promise anywhere in between the user click and the call to the api. Which is hugely ironic, since Mozilla is the one pushing to move all the webext APIs to be promise based (and provides a nice helpful library for Chrome/Edge/Safari support: https://github.com/mozilla/webextension-polyfill) which... doesn't work on their platform. Doubly ironic, since the result is that most FF extensions just ask for more permissions up front, which is exactly the opposite of what you'd want in the "secure/private" world Mozilla claims they're pushing towards.

I can't weigh in on the rest of your experience but I think the blame for the time synchronization issue lies squarely at your ISP's feet. Requesting that the time be properly synchronized to digitally sign something doesn't seem to be an absurd requirement to me. Blocking NTP on the other hand is quite insane IMO.

If I were in your situation and couldn't change ISP I'd probably buy a cheap GPS USB dongle just to have proper time sync on my network.

Stratux sells a u-blox 8 USB dongle that I've had decent luck with for this timekeeping purpose, although it can be tricky to get a clear signal indoors, and I had to bootstrap the module's first connection outside with usb-otg on a smartphone. But pretty acceptable results for under $20 when feeding it into ntpd. Not exactly plug and play to get it to work, though. But pretty reasonable for most of the diy crowd around here.

I need to tape over the green led due to photosensitivity, though. It's shockingly bright.

Do you mean it blocks incoming or outgoing ntp requests?

My old isp blocked port 25 inbound for security but I didn't consider that extreme