NTP server responses not being received

Question

I have set up my Windows 10 PC as an NTP server by setting HKLM\SYSTEM\CurrentControlSet\services\w32time\TimeProviders\NtpServer\Enabled=1.
I have added a firewall rule to allow inbound UDP traffic on port 123 and I have even tried disabling the firewall completely.
When a client sends an NTP request to the NTP server, the response is never received by the client.
I enabled logging via the command, "w32tm /debug /enable /file:C:\Temp\w32t.log /size:64000 /entries:0-300" and I can see that the Windows 10 PC receives the request from the client and sends a response but the client never receives the response (I verified this by running Wireshark on the client).
Below is an excerpt from the log file showing the request being processed and a response being sent.
I have to assume that the UDP send is failing but the log does not show that.
The Windows 10 PC that is set up as the NTP server has 2 network cards but I disabled the second card to make sure it was not causing the problem.
Could the problem be the fact that the NTP server is binding to 0.0.0.0 instead of the actual IP address for the interface?
Is there anything I can do to resolve this issue?

153568 15:44:42.0957115s - ListeningThread -- DataAvailEvent set for socket 1 (0.0.0.0:123)
153568 15:44:42.0958423s - HA Pkt Rcv: delay:0 DestTimeStamp:132683318820958249
153568 15:44:42.0958890s - Rx timestamp not returned and may be unsupported on the current network interface.
153568 15:44:42.0959285s - ListeningThread -- response heard from 192.168.1.151:123 <- 192.168.1.159:123
153568 15:44:42.0959992s - /-- NTP Packet:
153568 15:44:42.0960106s - | LeapIndicator: 3 - not synchronized; VersionNumber: 3; Mode: 3 - Client; LiVnMode: 0xDB
153568 15:44:42.0960318s - | Stratum: 0 - unspecified or unavailable
153568 15:44:42.0960451s - | Poll Interval: 10 - 1024s; Precision: -6 - 15.625ms per tick
153568 15:44:42.0960732s - | RootDelay: 0x0000.0000s - unspecified; RootDispersion: 0x0001.03FEs - 1.01559s
153568 15:44:42.0961070s - | ReferenceClockIdentifier: 0x00000000 - unspecified
153568 15:44:42.0961276s - | ReferenceTimestamp: 0xE4723DC8392ABEF0 - 13268176968223308500ns - 153566 20:42:48.2233085s
153568 15:44:42.0961603s - | OriginateTimestamp: 0x0000000000000000 - unspecified
153568 15:44:42.0961850s - | ReceiveTimestamp: 0x0000000000000000 - unspecified
153568 15:44:42.0962106s - | TransmitTimestamp: 0xE4749AEA3D435265 - 13268331882239308500ns - 153568 15:44:42.2393085s
153568 15:44:42.0962484s - >-- Non-packet info:
153568 15:44:42.0962661s - | DestinationTimestamp: 153568 15:44:42.0962805s - 0xE4749AEA1887FB0B153568 15:44:42.0962947s - - 13268331882095824900ns153568 15:44:42.0963106s - - 153568 15:44:42.0958249s
153568 15:44:42.0963304s - | RoundtripDelay: -143483600ns (0s)
153568 15:44:42.0963587s - | LocalClockOffset: 71741800ns - 0:00.071741800s
153568 15:44:42.0963950s - --
153568 15:44:42.0964698s - TransmitResponse: sent 0.0.0.0:123()->192.168.1.151:123

Answer 1

Hi,

Welcome to Q&A platform.

Could the problem be the fact that the NTP server is binding to 0.0.0.0 instead of the actual IP address for the interface?

Please try to configure the NTP server bind to the actual IP address for the interface to see if the issue still existed.

Best Regards,
Sunny

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.