none
Why do Windows NTP queries use port 123 for both source and destination? RRS feed

  • Question

  • I recently went through a lot of trouble trying to figure out why the time was not updating on my Windows PCs at home:

    https://answers.microsoft.com/en-us/windows/forum/windows_10-other_settings/unable-to-update-time-via-internet/bbff38f9-fa0d-445c-b03c-21d65607d8f5

    It turned out that the issue was apparently:

    1) When making NTP queries, Windows uses a source port of 123.
    2) My ISP (AT&T) blocks (usually?) inbound traffic on port 123.

    I've been able to get around that by adding a rule on my router to change the source port on outgoing NTP traffic to a random high numbered port.

    The question is, why does Windows use a source port of 123 for NTP queries? For client to server communication, source ports are usually high numbered random ports. Other tools (notably w32tm and NTPQuery) in fact use random high numbered ports for NTP queries, and those were working fine. From what I can see, using a source port of 123 is for server to server communication, which is not the case for a Windows desktop computer trying to keep its time in sync.

    Friday, April 3, 2020 7:13 PM

All replies

  • Looks like the RFC defines port 123 for both the client and the server..

    https://www.ietf.org/rfc/rfc5905.txt

    The following configuration variables are normally initialized when
       the association is mobilized, either from a configuration file or
       upon the arrival of the first packet for an unknown association.
    
       srcaddr: IP address of the remote server or reference clock.  This
       becomes the destination IP address in packets sent from this
       association.
    
       srcport: UDP port number of the server or reference clock.  This
       becomes the destination port number in packets sent from this
       association.  When operating in symmetric modes (1 and 2), this field
       must contain the NTP port number PORT (123) assigned by the IANA.  In
       other modes, it can contain any number consistent with local policy.
    
       dstaddr: IP address of the client.  This becomes the source IP
       address in packets sent from this association.
    
       dstport: UDP port number of the client, ordinarily the NTP port
       number PORT (123) assigned by the IANA.  This becomes the source port
       number in packets sent from this association.
    
       keyid: Symmetric key ID for the 128-bit MD5 key used to generate and
       verify the MAC.  The client and server or peer can use different
       values, but they must map to the same key.
    

    So, you can change to whatever port on the client to initiate the communication, but the RFC says that the client port should generally be 123..

    HTH
    -mario

    Friday, April 3, 2020 8:45 PM
  • No, it says the srcport must be 123 for symmetric modes, but in other modes it can contain any number consistent with local policy, which is typically a high numbered port. Queries to NTP servers from Windows desktops are in client mode, not one of the symmetric modes.
    Saturday, April 4, 2020 1:01 AM
  • May be it's for historical reason.. don't know, but if it is the way it works you should ask Microsoft why they choose this port..

    Thanks
    -mario

    Saturday, April 4, 2020 10:56 AM
  • You only need allow incoming traffic NTP's ports if you are acting as a server, allowing clients to sync to you.

    Otherwise, the existance of an NTP state will automatically determine whether the incoming NTP packet is blocked or allowed by an existing firewall state that we initiated.

    iptables -A OUTPUT -p udp --sport 123 --dport 123 -j ACCEPT

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    Please let me know if the iptables rules are proper. I have no experience with iptables. My NTP client stays synchronized on my pfSense router with only an outgoing allow rule because pfSense is a stateful firewall.
    Saturday, April 4, 2020 1:29 PM
  • May be it's for historical reason.. don't know, but if it is the way it works you should ask Microsoft why they choose this port..

    Thanks
    -mario

    That's why I'm posting here.
    Saturday, April 4, 2020 6:06 PM
  • You only need allow incoming traffic NTP's ports if you are acting as a server, allowing clients to sync to you.

    Otherwise, the existance of an NTP state will automatically determine whether the incoming NTP packet is blocked or allowed by an existing firewall state that we initiated.

    iptables -A OUTPUT -p udp --sport 123 --dport 123 -j ACCEPT

    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

    Please let me know if the iptables rules are proper. I have no experience with iptables. My NTP client stays synchronized on my pfSense router with only an outgoing allow rule because pfSense is a stateful firewall.

    That's normally true. However, some ISPs block port 123 incoming regardless if a request was initiated with that source port or not. Hence the problem.

    Saturday, April 4, 2020 6:08 PM
  • That's why I'm posting here.

    This is the sysinternals tools related forum.. you may have more chance asking in a Windows related forum than here.. may be there someone has source code access and can answer why it uses port 123 instead of a higher port..

    Did you already tried here:
    https://social.technet.microsoft.com/Forums/en-US/home?forum=win10itpronetworking

    Thanks!

    -mario

    Saturday, April 4, 2020 7:02 PM