Unable to update time via Internet

I have this same problem on the Windows 10 computers in my house. Connecting via hotspot on my phone did not help. Both my home internet and phone are using AT&T service. I called AT&T to have them open UDP port 123 inbound on my u-verse fiber connection which they said they did but. it seems they didn't really. Time sync threw the same old errors you documented. And ntpquery from bytefusion.com was unable to get a response from any time server I checked.

So, I started up my VPN (TorGuard) and went to sync time in the control panel. By the time I got it open it had already synced. ntpquery is able to get a response from any timeserver I care to check, as long as the VPN is running.

The problem in my case seems to be my ISP blocking the ports needed by the windows time service. Unfortunately ntpquery doesn't give me any information about the sending and receiving ports for the datagram and I don't have the chops to collect and parse stripcharts.

I expect I will rely on periodically connecting via VPN and syncing time while connected.

According to the port library used for Windows services, port 123 belongs to the Network Time Protocol. Provides time synchronization between computers and network systems

It should not be assigned to another protocol

The Windows Time System service maintains date and time synchronization on all computers on a network running Windows XP or later and Windows Server 2003 or later. This service uses the Network Time Protocol (NTP) to synchronize the clocks of the computers and thus assign a precise clock value and timestamp, for network validation and for resource access requests. The implementation of NTP and the integration of time providers make Windows Time a reliable and scalable time service for your company. For computers that are not joined to a domain, you can configure Windows Time to synchronize the time with an external source time. If this service is disabled, the time settings on local computers will not be synchronized with a time service in the Windows domain or with an externally configured time service. Windows Server 2003 uses NTP. NTP also runs on UDP port 123. The Windows 2000 version of this service uses Simple Network Time Protocol (SNTP). SNTP also runs on UDP port 123.

When the Windows Time Service uses a Windows domain configuration, it requires domain controller location and authentication services. Therefore, the ports for Kerberos and DNS are required.

System service name:

W32Time

Application protocol: NTP

Protocol: UDP

Ports: 123

Application protocol: SNTP

Protocol: UDP

Ports: 123

Source: https://support.microsoft.com/en-us/help/832017...

Glad To help

I don't think you're understanding the issue. NTP servers run on port 123. That isn't in question, nor is it a problem. When a Windows PC queries an NTP server, the destination port is necessarily 123, the port the NTP server is listening on. However, Windows is also setting the source port - the port the Windows PC is waiting for a response from the server on - to 123. The problem is that some ISPs (notably AT&T) block incoming traffic on port 123, so responses from NTP servers are lost.

Typically, client requests use random, high numbered source ports:

"NTP is a UDP -based service. NTP servers use well-known port 123 to talk to each other and to NTP clients. NTP clients use random ports above 1023. As with DNS , you can tell the difference between:

• An NTP client-to-server query - source port above 1023, destination port 123.
• An NTP server-to-client response - source port 123, destination port above 1023.
• An NTP server-to-server query or response - source and destination ports both 123."

https://docstore.mik.ua/orelly/networking/firewall/ch08\_13.htm

As noted, port 123 is used for both source and destination for server to server queries, but Windows is just acting as a client, not a server.

NTP is a UDP -based service. NTP servers use well-known port 123 to talk to each other and to NTP clients. NTP clients use random ports above 1023. As with DNS , you can tell the difference between: An NTP client-to-server query - source port above 1023, destination port 123. An NTP server-to-client response - source port 123, destination port above 1023. An NTP server-to-server query or response - source and destination ports both 123. docstore.mik.ua/orelly/networking/firewall/ch08_13.htm

NTP is a UDP -based service. NTP servers use well-known port 123 to talk to each other and to NTP clients. NTP clients use random ports above 1023. As with DNS , you can tell the difference between: An NTP client-to-server query - source port above 1023, destination port 123. An NTP server-to-client response - source port 123, destination port above 1023. An NTP server-to-server query or response - source and destination ports both 123. docstore.mik.ua/orelly/networking/firewall/ch08_13.htm

I just tried a Mac on my network to see if a clock update via NTP would work, and it worked repeatedly. Trying again on my Windows 10 desktop, it has mostly been working since.

I've also since been using Wireshark to monitor traffic on UDP port 123. An interesting thing to note is that while updating the time using the control panel uses NTP version 3, running a stripchart using w32tm uses NTP version 1.

Ok, looking some more, I have a feeling I know what the problem is. When issuing queries using NTPQuery and w32tm's stripchart, the destination port is 123 (the port the NTP server is running on) and the source port is a random, high numbered port (usually the case for clients). However, when trying to update the time via the Date and Time control panel, the source and destination ports are both 123. Some Googling suggests that my ISP (AT&T) does blocking (some of the time, anyway) on port 123 inbound, which would definitely cause this problem.

Some more Googling led me to this iptables entry, which translates a source port of 123 to a random high numbered port:

iptables -t nat -p udp -I POSTROUTING -o WAN_INTERFACE_NAME --sport 123 -j MASQUERADE --to-ports 49152-65535 --random

Where "WAN_INTERFACE_NAME" is the name of the WAN interface on the router.

And...at least at the moment, it seems like that has resolved the issue. However, it's unclear why Windows is using port 123 as the source port for client communications.

In the following link is the description why the port is 123-123 and its form of communication

Network time protocol

https://tools.ietf.org/html/rfc958#appendix-A

Note: This is a non-Microsoft website. The page appears to be providing accurate, safe information. Watch out for ads on the site that may advertise products frequently classified as a PUP (Potentially Unwanted Products). Thoroughly research any product advertised on the site before you decide to download and install it.

As stated:

   Source Port

      UDP source port number. In the case of unsymmetric mode and a
      client request this field is assigned by the client host, while
      for a server reply it is copied from the Destination Port field of
      the client request.  In the case of symmetric mode, both the
      Source Port and Destination Port fields are assigned the NTP
      service-port number 123.

   Destination Port

      UDP destination port number. In the case of unsymmetric mode and a
      client request this field is assigned the NTP service-port number
      123, while for a server reply it is copied form the Source Port
      field of the client request.  In the case of symmetric mode, both
      the Source Port and Destination Port fields are assigned the NTP
      service-port number 123.

That is to say, the source port is generally *not* 123 in client to server communication (unsymmetric mode). Also:

   There is no provision for peer discovery, acquisition, or
   authentication in NTP.  Data integrity is provided by the IP and UDP
   checksums.  No reachability, circuit-management, duplicate-detection
   or retransmission facilities are provided or necessary.  The service
   can operate in a symmetric mode, in which servers and clients are
   indistinguishable yet maintain a small amount of state information,
   or in an unsymmetric mode in which servers need maintain no client
   state other than that contained in the client request.  Moreover,
   only a single NTP message format is necessary, which simplifies
   implementation and can be used in a variety of solicited or
   unsolicited polling mechanisms.

   In what may be the most common (unsymmetric) mode a client sends an
   NTP message to one or more servers and processes the replies as
   received.  The server interchanges addresses and ports, fills in or
   overwrites certain fields in the message, recalculates the checksum
   and returns it immediately.  Information included in the NTP message
   allows each client/server peer to determine the timekeeping
   characteristics of its other peers, including the expected accuracies
   of their clocks. Using this information each peer is able to select
   the best time from possibly several other clocks, update the local
   clock and estimate its accuracy.

A Windows desktop computer querying Internet based NTP servers is not running in unsymmetric mode.

Hi lukpac

I'm Wilfredo S an Independent Advisor

You can register the time service again.

In the Windows search engine type CMD or command prompt when leaving the icon run as administrator

And place the following commands:

run them one by one

net stop w32time

w32tm / unregister

w32tm / register

net start w32time

Check if the problem still persists

I hope it helps you