5 ms·

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 inte

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.

manquer 5y ago
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.
magnat 5y ago
NTP is commonly used for DDoS amplitication.
- wbl 5y ago
  The right way to do this is to police, not block, and by length.
addingnumbers 5y ago
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.
- hda2 5y ago
  Can you please share the iptables rule?
  - addingnumbers 5y ago
    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.

manquer 5y ago

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.

magnat 5y ago

NTP is commonly used for DDoS amplitication.

wbl 5y ago
The right way to do this is to police, not block, and by length.

addingnumbers 5y ago

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.

hda2 5y ago
Can you please share the iptables rule?
- addingnumbers 5y ago
  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.