NTP port guide: time synchronization on UDP 123

An NTP client periodically sends a request to one or more time servers over UDP 123. The server returns timestamps that let the client estimate offset, delay, and jitter, then the client adjusts its local clock without making disruptive jumps unless the drift is too large.

NTP deployments are often arranged in strata. Stratum 0 is a reference clock such as GPS or an atomic source. Stratum 1 servers connect directly to those references, and lower-stratum servers distribute time further into the network. Most organizations should use trusted upstream sources and provide internal NTP to their own systems.

An NTP client needs outbound access to UDP 123 toward its configured time sources. An NTP server needs inbound UDP 123 from the clients it is meant to serve. Those are different firewall questions, and mixing them up is a common source of broken time sync.

Workstations and application servers usually act only as clients. Domain controllers, network time appliances, monitoring infrastructure, and internal time hubs may act as servers for the rest of the fleet.

Allow outbound UDP 123 from systems that need to synchronize with trusted external or internal time sources. Allow inbound UDP 123 only on servers that are intentionally providing NTP to known clients.

Do not expose an NTP server broadly to the internet unless it is intentionally operated as a public time service with capacity, rate limiting, monitoring, and abuse controls. Misconfigured public NTP can be abused for reflection and amplification attacks.

Before allowing UDP 123, decide which systems are clients, which systems are servers, and which upstream time sources are trusted. Confirm whether your environment uses chrony, systemd-timesyncd, ntpd, Windows Time Service, a domain hierarchy, or a dedicated appliance.

A port checker can help with reachability, but time sync must also be verified at the protocol and clock level. Use chronyc, ntpq, w32tm, timedatectl, or monitoring data to confirm offset, stratum, source selection, and drift.

On Windows domains, Windows Time Service usually synchronizes domain members through the domain hierarchy, with the PDC emulator configured against trusted upstream sources. Standalone Windows servers can be configured with w32tm and firewall rules for UDP 123 when they serve time.

On Linux, chrony is common on modern distributions, while ntpd and systemd-timesyncd also appear. Configure trusted pools or internal servers, allow UDP 123 only where the host provides time, and monitor offset and source health.

On network devices, point switches, routers, firewalls, and appliances at internal NTP sources where possible. Accurate device time makes logs, certificates, VPNs, and incident investigations far more reliable.

Start by checking whether UDP 123 is reachable between the client and the intended time server. Then verify actual synchronization with chronyc tracking, chronyc sources, ntpq -p, timedatectl timesync-status, or w32tm /query /status depending on the platform.

If you operate an NTP server, test from a known client network and confirm that unauthorized networks cannot query it. For internet-facing services, watch request volume and response patterns because reachability alone does not prove safe configuration.

If NTP is not syncing, the client may be blocked from UDP 123, using the wrong server, rejecting a source due to high offset, or unable to resolve the time server hostname. Virtual machines can also drift if host time, guest tools, and NTP are fighting each other.

If a server is reachable but clients still drift, inspect stratum, leap status, source selection, firewall state, NAT behavior, and whether multiple time systems are configured at once. For Windows domains, verify the domain time hierarchy before changing every host individually.

Restrict who can query your NTP servers, disable obsolete high-amplification commands, keep NTP software patched, and monitor unusual traffic spikes. Prefer internal time distribution over letting every host query random public servers.

For important environments, use multiple trusted time sources, alert on excessive offset, document the authoritative time path, and include time sync in incident response checks. Bad time can break certificates, authentication, log correlation, and scheduled jobs.