VMware ESXi and vSphere Cluster Management

Configure a Linux NTP Server and Clients with ntpd

Install and configure ntpd on Debian or Ubuntu, secure clients with restrict rules, allow UDP 123, configure Linux clients, and verify synchronization with ntpq.

What an NTP server does

NTP (Network Time Protocol) synchronizes computer clocks across a network. Consistent time is important for log correlation, authentication systems, scheduled jobs, certificate validation, distributed applications, databases, and incident troubleshooting. Even small clock differences can make events appear out of order or cause time-sensitive operations to fail.

An ntpd host normally has two roles:

• It obtains time from several upstream NTP servers or pools.
• It provides time to authorized downstream NTP clients on the local network.

Configure multiple independent upstream sources instead of relying on one server. ntpd evaluates the available sources and selects a suitable synchronization source; it does not blindly trust every configured source.

A typical design is: external time sources provide time to an internal Linux server, and that server provides time to workstations, servers, and network devices. The internal service should not be treated as a trusted time source until it is synchronized upstream, unless a deliberately designed fallback strategy is in place.

Prerequisites and terminology

This lesson assumes basic Linux administration, sudo, text editing, IPv4 addressing, subnet masks or CIDR notation, service management, and firewall concepts.

Install the traditional ntpd service

On Debian and Ubuntu-style systems, the traditional NTP daemon is supplied by the ntp package:

sudo apt-get update && sudo apt-get install ntp

ntpd is the traditional NTP daemon. It is different from chrony and systemd-timesyncd, which are alternative time-synchronization services. Normally, only one service should control the system clock and listen for NTP traffic. Before enabling ntpd, identify existing time services and check whether UDP port 123 is already in use.

systemctl status chrony systemd-timesyncd ntp 2>/dev/null
sudo ss -ulnp | grep ':123'

If chrony, systemd-timesyncd, or another NTP daemon is active, decide which service your system will use. Disable or remove a competing service according to your operating system's administration policy before starting ntpd.

Understand /etc/ntp.conf

The primary configuration file for traditional ntpd is /etc/ntp.conf. Make a backup before editing it, then open it with a text editor:

sudo cp /etc/ntp.conf /etc/ntp.conf.backup
sudo nano /etc/ntp.conf

The most important directives for a basic server are:

• server or pool: defines upstream time sources.
• driftfile: stores the clock-frequency correction learned by ntpd.
• restrict: controls which remote hosts may query the daemon and which operations they may perform.

A drift file helps ntpd stabilize more quickly after a restart because it preserves an estimate of how fast the local hardware clock gains or loses time. Keep the configured drift-file path writable by the ntpd service. A common configuration contains a line similar to:

driftfile /var/lib/ntp/ntp.drift

Distribution packages may provide additional default restrictions or a different drift-file path. Preserve valid distribution defaults unless you understand why they should change.

Configure several upstream time sources

Retain or add several suitable internet NTP servers or pool entries. For a small office server, an example is:

pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst
pool 2.pool.ntp.org iburst

iburst allows faster initial polling when the daemon starts. Choose sources that are reachable from the server and appropriate for your organization, region, and network policy. Some organizations provide approved internal or regional NTP sources instead of using public pools.

Multiple sources improve resilience and allow ntpd to reject a source that is unreachable or inconsistent. DNS resolution, routing, NAT policy, and outbound firewall rules must permit the server to contact the selected sources over UDP port 123.

Restrict access to authorized client networks

The restrict directive controls remote access to ntpd. A network address combined with a subnet mask identifies the permitted client range. For example, this rule permits clients on 192.168.198.0/24 to use the service:

restrict 192.168.198.0 mask 255.255.255.0 nomodify notrap

Replace both the network address and mask with your own client network. A /24 network uses the mask 255.255.255.0; it covers addresses from 192.168.198.1 through 192.168.198.254 for this example.

• nomodify prevents remote clients from modifying the daemon's configuration or operating state.
• notrap prevents remote control-message trap configuration.

Keep restrictive default rules for untrusted networks. Do not expose an internal time service to the public internet merely to make client configuration easier. Add narrowly scoped rules for only the internal subnets that require service. Basic IP-based restrictions control who may connect; they are not the same as cryptographic NTP authentication.

Network and firewall requirements

NTP uses UDP port 123. The server needs:

• Inbound UDP 123 allowed from the intended client networks.
• Outbound UDP 123 allowed to the configured upstream sources.
• Working routes and DNS resolution when pool or hostname-based sources are used.

For a UFW-managed host, this example allows only the sample LAN to reach NTP:

sudo ufw allow from 192.168.198.0/24 to any port 123 proto udp

Also check network firewalls, cloud security groups, VLAN routing, NAT policies, and egress filtering. A local host firewall rule cannot compensate for a blocked route or upstream policy.

Start, reload, and enable ntpd

After editing /etc/ntp.conf, reload or restart ntpd. A reload is usually sufficient for configuration changes; a restart is useful when diagnosing startup or binding problems.

sudo service ntp reload
sudo systemctl restart ntp
sudo systemctl status ntp
sudo systemctl enable ntp

Use the service-manager commands appropriate for the distribution. Check status and logs after changing the configuration. If the service fails to start, inspect the status output and system logs for syntax errors or a port conflict.

Configure Linux NTP clients

Each client needs an NTP client service. It may use ntpd, chrony, or another supported client, but do not run several independent time services at once. Install and configure the chosen client service according to the operating system policy.

In a client using traditional ntpd, edit its /etc/ntp.conf and replace or supplement public upstream entries with the internal server's private address or hostname. For example:

server 192.168.198.10 iburst

Use the actual address of your internal NTP server. If the client is meant to use only the local server, remove or comment out other sources when appropriate. Then reload or restart the client service:

sudo service ntp reload
sudo systemctl restart ntp
sudo systemctl status ntp

The client must have IP connectivity to the server, and UDP 123 must be allowed between the client subnet and the server. Confirm that the server's access rule includes the client's network.

Verify synchronization with ntpq

ntpq is a command-line query tool for inspecting ntpd peers and synchronization status. Run it on the server:

sudo ntpq -p

A representative result might look like this:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*upstream-a      .GPS.             2 u   32   64   377    18.4   -0.821   1.204
+upstream-b      .PPS.             2 u   30   64   377    21.1    0.412   1.876
-upstream-c      .ATOM.            2 u   29   64   377    25.8    2.031   2.447

The exact values vary with network conditions and polling state. Look for a selected source and healthy reachability rather than expecting exact numbers.

Verify both sides of the hierarchy. The server must select a valid upstream source before clients can receive trustworthy time. Then run sudo ntpq -p on a client and confirm that the internal server is present and selected.

Configuration reference

Troubleshoot common failures

When ntpd will not start

Invalid syntax in /etc/ntp.conf and an existing process bound to UDP 123 are common causes. Check:

sudo systemctl status ntp
sudo journalctl -u ntp --no-pager
sudo ss -ulnp | grep ':123'

Correct configuration errors, then disable the conflicting daemon before starting ntpd.

When the server has no selected source

A missing selected peer can indicate no route to upstream servers, DNS failure for pool names, blocked outbound UDP 123, or unavailable configured sources. Review peer reachability, test DNS and network access under your organization's rules, and retain several valid upstream sources.

When clients reach the server but time is unstable

First verify the server's own selected source, offset, and reachability. If the server is unsynchronized, repair it before diagnosing every client. Then check client peer statistics, packet loss, network latency, and competing time services. Only one intended service should control each system clock.

Security and operational guidance

• Limit NTP access to the internal subnets that need it.
• Do not advertise an unsynchronized server as a trusted time source.
• Keep the operating system and NTP software updated.
• Review ntpd logs, selected peers, reachability, offset, and stratum periodically.
• Use NTP authentication when the environment requires protected NTP exchanges. Authentication provides protection for trusted exchanges; it does not replace restrictive IP-based access control.
• Document upstream sources, authorized client networks, firewall rules, and the fallback plan for upstream outages.

Next steps

For a related configuration walkthrough, see Configure NTP Server. In production environments, also compare ntpd with chrony, review your firewall's UDP service policy, and establish monitoring for synchronization loss.