Fix NTP sync issues: Make sure time service is running, UDP 123 outbound port is open, the servers you set are actually responding to ntpq -p or w32tm /query /peers, and correct as necessary peer, stratum and offset errors. Resync using tsc /resync (see above) and observe drift in your log.
Symptoms
- Log timestamps across servers differ by seconds or minutes, breaking correlation in your SIEM
- Kerberos or AD authentication fails with clock skew errors above five minutes
- ntpq -p shows reach as 0 or an asterisk missing next to any peer
- chronyc tracking reports Leap status: Not synchronised or a very high Last offset
- Scheduled tasks, cron jobs, or TLS handshakes fire at the wrong moment or fail unexpectedly
Common Causes
UDP port 123 blocked upstream
A firewall, NAT device, or ISP filter drops outbound NTP traffic. The daemon runs happily but every poll times out, so peers never reach a usable state.
Wrong or unreachable server pool
The config still points at a decommissioned internal appliance or a country pool that resolves to dead hosts. DNS resolves, but no valid stratum response comes back.
Conflicting time services on Windows
W32Time is running alongside a third-party client, or Hyper-V time integration is forcing the host clock. The two fight and the effective offset oscillates.
Virtual machine clock drift
VMs pause, migrate, or lose CPU cycles, which starves the kernel clock. Without host time sync or a tight NTP poll interval, offsets grow into the seconds range.
Stratum or peering loop
Two internal servers peer with each other but neither has a real upstream source. They agree on a wrong time and refuse better external peers.
Step-by-Step Fix
- Verify the offset and sync status:
Begin with facts, not speculation. Linux: timedatectl status; ntpq -p (or chronyc tracking for chrony). Windows: w32tm /query /status; w32tm /query /peers. Record the offset, stratum, and the peer, if any, with an asterisk next to it. - Confirm the time daemon is running:
This leads to a service that has stopped after a patch cycle. On Linux, run systemctl status chronyd or systemctl status ntp; restart if down. On Windows, run Get-Service w32time followed by Restart-Service w32time. Look for errors in the journal or Event Viewer. - Attempt to reach your NTP peers on UDP 123:
ICMP ping does not give any information about NTP. On Linux: ntpdate -q pool.ntp.org or chronyc sources -v. On both OS's: sudo nmap -sU -p 123 your.ntp.It shows the port responds. If packets are being lost, ask your network team to open UDP 123 out and in for replies. - Confirm and troubleshoot server configuration (if secondary):
Check the server config at /etc/chrony/chrony.conf or /etc/ntp.conf and delete non-working entries. For variety, use a pool like 0.pool.ntp.org through 3.pool.ntp.org with iburst or your own secondary stratum-2 servers. On Windows: use w32tm /config /manualpeerlist:"time.windows.com,0x8" /syncfromflags:manual /update. - Force a resynchronization and watch it converge
Restart the service, then push a manual sync. Linux: sudo chronyc makestep or sudo ntpd -gq. Windows: w32tm /resync /force. Re-run ntpq -p after two or three minutes. A healthy peer shows reach climbing toward 377 octal and a small, stable offset. - Eliminate competing time sources on virtual hosts
On Hyper-V guests, disable the Time Synchronization integration service if the VM already runs NTP, otherwise the hypervisor overrides you. On VMware, decide once: either tools.syncTime = FALSE plus NTP inside the guest, or host-only sync. Never mix both. - Audit stratum, peering, and internal hierarchy
In multi-site environments, designate two or three internal servers as your stratum-2 layer pointing at public pools, and have everything else chase them. Avoid peering internal servers with each other as their only source, which creates a self-referencing loop with no real upstream. - Establish drift monitoring before you close the ticket
Export the offset from chronyc tracking or w32tm /stripchart into your monitoring system and alert when it exceeds 500 ms. Drift usually returns quietly after a reboot or firewall change, so continuous visibility matters more than a one-time fix.
Common NTP symptoms mapped to likely cause and first action
| Symptom | Likely cause | First action |
|---|---|---|
| ntpq -p shows reach = 0 for every peer | UDP 123 blocked outbound | Test with nmap -sU -p 123 and open the firewall |
| Offset grows steadily then jumps | Hypervisor time sync fighting the guest daemon | Disable host time integration or the guest NTP client |
| Windows clients drift, domain controllers do not | Clients not honouring the PDC emulator | Reset w32tm config and point clients at the PDC |
| Leap status: Not synchronised in chrony | No selected peer despite responses | Check stratum values and remove looping internal peers |
| Sudden skew after patch Tuesday | Time service failed to restart | systemctl status chronyd or Restart-Service w32time |
| Auth fails with clock skew > 5 min | Large offset exceeds Kerberos tolerance | Force chronyc makestep or w32tm /resync /force |
Prevention
- Alert on NTP offset above 500 ms and on any peer with reach = 0 for over 15 minutes
- Document a single authoritative internal time hierarchy and forbid ad-hoc peer changes
- Include UDP 123 outbound in your firewall change-review checklist
- Disable hypervisor time integration on any guest that runs its own NTP client
FAQ
How precise should NTP be within a standard corporate network?
For your general server and workstation use, keeping offset less than 100 ms against your stratum-2 source is not too shabby. Kerberos will allow five minutes, but TLS and log correlation will require a lot tighter. If you are in finance trading, telecom, or regulated audit, use sub-millisecond PTP rather than NTP.
When should I use ntpd/chrony/systemd-timesyncd in Linux?
Chrony is the latest default on the majority of the big distributions and handles not online computers, notebooks, and vms in a much more elegant fashion than classic ntpd. Systemd-timesyncd is a low-footprint SNTP client made for endpoints unable to provides time to other PCs. Opt for chrony for servers unless you have a rational to do otherwise.
Why do I see w32tm synchronized, but my time is still wrong?
The source of the sync is typically wrong, not the sync. A domain-joined machine will always sync from the PDC emulator whatever you set manually, and the PDC could be misconfigured. Run w32tm /query /source and correct the configuration on the PDC emulator so that the entire domain syncs from it.