Changed NTP port back to 123: IPv6 Monitor fails

[boretom]

The server ch1.ntspool.telnet.li was running with NTP port set to 4123 for some days. Yesterday I switched back to 123 and since then the IPv6 monitor is not happy with it.

This morning I switched back to 4123 for a short time and the IPv6 score started to increase. Switched back to 123 and it fails again. Every so often a probe succeeds but mostly not.

In my youthful arrogance I feel like the NTP server itself is working fine. chronyd -Qt 5 nts ... works for both IPv4 and IPv6. Is it possible the IPv6 monitor is still trying to use port 4123 for some part?

The server itself is a bit odd as in that IPv6 is configured on interface 0 (vio0) and IPv4 is configured on interface 1 (vio1). That is the way the cloud provider is doing it.

The log entries look like the following:

Time | Key exchange | Ntp (cookie from KE) | Ntp (cookie from NTP)
2026-01-30 06:48 | Success (duration: 666.8ms) | Success (RTT: 21.9ms, offset: -2.7ms) | Timeout

and a raw sample:

{
  "keyexchange": {
    "description": "",
    "exchange_duration": 0.666764333,
    "exchange_start": 1769755689,
    "num_cookies": 8,
    "status": "Success"
  },
  "ntp_with_ke_cookie": {
    "leap_indicates_synchronized": true,
    "offset": -0.0027462407021658125,
    "received_cookies": 2,
    "remote_residence_time": 0.0001836277079264698,
    "request_sent": 1769755689,
    "requested_cookies": 2,
    "roundtrip_duration": 0.021940667885807497,
    "status": "Success",
    "stratum": 2
  },
  "ntp_with_ntp_cookie": {
    "leap_indicates_synchronized": false,
    "offset": null,
    "received_cookies": 0,
    "remote_residence_time": null,
    "request_sent": 1769755690,
    "requested_cookies": 3,
    "roundtrip_duration": null,
    "status": "Timeout",
    "stratum": null
  }
}

[davidv1992]

Having had a look at when the failures occur, it seems to be only when we are testing if you are able to provide 3 cookies. This suggests that this is some AS on the path between us and you that is either filtering out the request or the response NTP package when using port 123.

It is unfortunately a fact of life that there are many AS operators that filter NTP packets they consider "too large", because of the management protocol being on by default on some NTP servers running older versions of NTP classic. This means that it is not entirely unexpected that things may function better over 4123 compared to 123.

[boretom]

Thank you for the quick answer and your analysis.

I'll check with the hoster because it only happens with IPv6 but not IPv4. And the hoster is pushing for IPv6-only VMs for quite some time. It may well be out of their control, let's see with whom they do their pairing peering.

[boretom]

The hoster got back to me and as suspected: they don't filter and there's nothing they can do.