<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
On 4/9/2024 7:19 AM, Steven Sommars via users wrote:<br>
<blockquote type="cite"
cite="mid:CAD4huA7XvkVw6UAV7LeY=ynaWXaHK7xaNmSXqB=eGjaPQbZBUA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">I've examined NTP filtering quite a bit. IPv4 is
more filtered than IPv6 See <a
href="https://weberblog.net/ntp-filtering-delay-blockage-in-the-internet/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://weberblog.net/ntp-filtering-delay-blockage-in-the-internet/</a>
for an analysis from 2020.
<div>The NTP blocks can change over time. From recent scans I
see Comcast blocks port 123 for UDP size not equal to 56 (NTP
payload is 48 bytes). </div>
<div>I saw this from two residential locations, one near Chicago
and one near Denver. For my local system this block was
added on about 2023-02-14.</div>
<div>Level 3 is a big offender.</div>
<div><br>
</div>
<div>With some work you can use traceroute or similar tools such
as mtr to probe for blocks in the outgoing direction. </div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>mtr -n -s 450 -u -P 123 IPv4_address </div>
</blockquote>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px">
<div>-s sets the payload size. -P set the outgoing port
number.</div>
</blockquote>
<div>CAUTION. I've found argument parsing bugs in some
traceroute and mtr versions. The above example works for
mtr version 0.95 but doesn't work for version 0.85</div>
<div>I use tcpdump/wireshark to verify that outgoing probe
packets have UDP destination port set to 123 and that they
have the expected size.</div>
<div><br>
</div>
<div><font face="monospace">-P 123 NTP (UDP port 123) size
450 is blocked in local ISP, can't tell where<br>
Packets
Pings<br>
Host Loss% Snt Last Avg
Best Wrst StDev<br>
1. local_system 0.0% 3 1.3 1.2
1.2 1.3 0.0<br>
2. (waiting for reply)<br>
<br>
-P 122 UDP port 122 size 450 is not blocked</font></div>
<div><font face="monospace">
Packets Pings<br>
Host Loss% Snt Last Avg
Best Wrst StDev<br>
1. local_system 0.0% 16 1.3 1.1
0.8 1.3 0.2<br>
2. (waiting for reply)<br>
3. (waiting for reply)<br>
4. 12.242.117.29 0.0% 16 10.7 9.8
6.2 13.1 2.6<br>
5. 192.205.37.42 0.0% 16 7.9 9.6
7.4 18.7 3.5<br>
6. 171.75.8.101 0.0% 16 151.9 154.2
151.4 164.3 3.5<br>
7. 62.67.67.154 0.0% 16 152.2 152.9
151.5 157.4 1.5<br>
8. 188.1.144.134 0.0% 16 157.3 185.6
157.2 255.3 42.5<br>
9. (waiting for reply)</font></div>
</div>
</blockquote>
<br>
Thanks for the reply and the info regarding use of mtr. I've done a
bunch of tests today between my mailserver in AWS, my webserver in
the Oracle cloud, and my timeserver here on comcast/xfinity - both
directions, different packet sizes, watching tcpdump output on both
sides, using mtr, netcat, etc.. When my timeserver sends more than
48 bytes to either cloud server over UDP port 123, they will reach
the destination server, but the reply back will not reach my
timeserver. <br>
<br>
I set up both my mailserver and my webserver to both run NTS. No
problem communicating between the two. So, comcast/xfinity blocks
large UDP packets on port 123, as you described.<br>
<br>
It appears that I can no longer provide NTS timeservice to the
outside world. This sort of widespread blocking can only further
hinder adoption of NTS.<br>
<br>
<pre class="moz-signature" cols="74">--
Paul Theodoropoulos
<a class="moz-txt-link-abbreviated" href="http://www.anastrophe.com">www.anastrophe.com</a></pre>
</body>
</html>