Let's start with this example. When I click sync my clock in windows, this happened.
On the inside or Private side 08:15:07.434344 IP 192.168.254.205.123 > 13.86.101.172.123: NTPv3, Client, length 48 08:15:07.473681 IP 13.86.101.172.123 > 192.168.254.205.123: NTPv3, Server, length 48 You are indeed right that the client must use UDP port 123. Is the RFC saying must or should on the client SRC port? I'm not sure. But, on the Public, this happened. 08:15:07.434381 IP 192.2XX.XXX.58291 > 13.86.101.172.123: NTPv3, Client, length 48 08:15:07.473656 IP 13.86.101.172.123 > 192.2XX.XXX.58291: NTPv3, Server, length 48 // Public ip obfuscated. I know, it indeed starts with 192.2. It's EBOX in Canada. What we see on the public side, is that a network device did a NAT translation of the SRC UDP port to 58921. My clock synced perfectly. So your goal is to find the devices that don't follow this behaviour, right? Jean -----Original Message----- From: Fernando Gont <fernando.g...@edgeuno.com> Sent: June 10, 2021 7:09 AM To: j...@ddostest.me; nanog@nanog.org Subject: Re: NAT devices not translating privileged ports Hi, Jean, On Thu, 2021-06-10 at 06:54 -0400, Jean St-Laurent via NANOG wrote: > Hi Fernando, > > NTP sounds simple but it could be very complex when you dig deep down > and/or get lost in details. > Here are 2 things to consider: > > 1. NTP clients can query NTP servers by using SRC UDP ports > 1024. This is indeed the case we're addressing. The NTP spec mandates srt port=123, even for client-to-server cases.
