2026-06-02

NTP Clock Drift Packet Capture Analysis: Time Sync Failures, Offset, Delay, Jitter, and Firewall Issues

How to analyze NTP time synchronization failures in packet captures, including offset, delay, jitter, missing responses, wrong servers, firewall blocks, and clock drift symptoms.

Expired-looking TLS certificates, out-of-order logs, Kerberos failures, and wrong camera timestamps can all be secondary effects of clock drift. A time-sync capture should establish whether NTP requests leave on UDP 123, which server responds, poll cadence, stratum, offset-related timestamps, delay, and packet loss rather than assuming the network owns the clock error. It can prove exchange timing and missing responses; oscillator quality and the host daemon's correction policy remain host-side evidence. PCAP Surgery is useful because NTP packets are small and easy to remove accidentally when trimming a larger troubleshooting capture.

What NTP uses

NTP usually uses UDP port 123. A client sends a request to a time server, and the server replies with timestamps used to estimate offset and delay.

If requests leave and no responses return, the issue may be firewall, routing, server reachability, DNS, or local policy. If responses arrive but time still drifts, inspect server choice, polling behavior, and system clock behavior.

Common symptoms

NTP issues appear as:

Time drifts minutes or hours.
TLS certificate "not yet valid" or "expired" errors.
Kerberos authentication failure.
Logs from multiple systems do not line up.
Packet timestamps look inconsistent across captures.
NVR/camera recordings show wrong time.
Distributed tracing spans appear negative or out of order.

The root cause may be NTP, but applications report higher-layer failures.

Packet evidence

Capture:

Client NTP requests.
Server responses.
Source and destination IPs.
Poll interval.
Stratum where visible.
Leap/status fields where decoded.
Round-trip timing.
Missing responses.
ICMP unreachable messages.

If the client sends to the wrong server, the trace reveals it.

Firewall and NAT issues

UDP 123 may be blocked outbound, inbound, or by policy. Some networks allow DNS and HTTPS but block NTP. Some environments force clients to use internal time servers.

Symptoms:

Requests repeat with no response.
ICMP Port Unreachable appears.
External NTP blocked, internal NTP works.
VPN changes time server reachability.

Time quality vs reachability

A server can answer but still not be a good time source. NTP quality depends on server stability, network delay, jitter, stratum, and client discipline behavior. A pcap alone may not prove oscillator quality, but it can show packet timing and server selection.

For serious drift, combine packet evidence with OS time-sync logs.

Checklist

Use this workflow:

Filter UDP port 123.
Identify configured NTP servers.
Check whether requests leave.
Check whether responses return.
Inspect response timing.
Look for ICMP unreachable.
Compare internal vs external NTP.
Preserve NTP packets when trimming larger traces.
Correlate with system time-sync logs.
If comparing captures, ensure capture hosts are time-synchronized.

Final diagnosis

NTP packet analysis can distinguish blocked time traffic, unreachable servers, wrong server configuration, missing responses, poor timing path, and higher-layer symptoms caused by clock drift.

PCAP Surgery helps preserve the small NTP evidence that often explains much larger authentication, TLS, logging, and distributed-system problems.

Understand the four NTP timestamps

An NTP exchange uses originate, receive, transmit, and destination times to estimate offset and network delay. The client’s destination timestamp comes from its local clock, so severe clock problems and asymmetric paths affect interpretation. Prefer the NTP daemon’s own computed offset/jitter logs alongside the packet trace.

Field	Meaning
Originate	Client transmit time echoed by server
Receive	Server time when request arrived
Transmit	Server time when response left
Destination	Client time when response arrived

The simplified estimates assume path symmetry:

offset ≈ ((T2 - T1) + (T3 - T4)) / 2
delay  ≈ (T4 - T1) - (T3 - T2)

Large path asymmetry can bias offset. A PCAP timestamp from a separately synchronized tap can validate exchange timing, but a capture on the drifting host may inherit that host’s clock error.

NTP response quality table

Observation	Interpretation lead
Requests, no replies	Firewall, route, server, or capture visibility
Stratum 16/unsynchronized	Server is not a valid sync source
Kiss-o'-Death response	Rate/policy restriction
Large variable RTT	Path jitter degrades time estimate
Several servers disagree	Source quality, path, or clock issue
Replies arrive, daemon never disciplines	Host config/state/permissions

Check leap indicator, stratum, reference ID where meaningful, root delay/dispersion, poll interval, and server selection. Do not choose a source solely because it answers UDP 123.

Can a firewall permit requests but block replies?

Yes. Capture inside and outside the boundary, map NAT, and inspect ICMP or policy counters. UDP state timeout and asymmetric routing can also affect replies.

Why can NTP work outside VPN but fail inside?

The VPN may change routes, DNS-resolved server, policy, NAT, MTU, or force internal time sources. Compare server addresses and captures in both states.

Does one successful NTP reply prove synchronization?

No. Synchronization requires repeated acceptable samples and daemon discipline. Host logs show selected peer, offset, frequency correction, step/slew policy, and rejection reasons.

Step versus slew and application impact

A large offset may be stepped immediately or corrected gradually, depending on daemon policy and boot state. Stepping can make logs/capture timestamps jump; slewing leaves temporary offset. Record when correction occurred and how capture tooling timestamps packets.

For TLS, Kerberos, databases, and distributed traces, compare incident time with correction. Fixing NTP later does not retroactively make old logs aligned. Preserve original time sources and estimate uncertainty.

Multi-host timeline alignment

Use several shared packet events across captures, not one. Calculate offset at beginning and end to detect drift. If clocks diverge linearly, document a model and residual error; do not rewrite originals. Follow the PCAP timestamp evidence guide.

Alignment result	Safe claim
Constant offset, low residual	Relative cross-host timing can be corrected with stated uncertainty
Offset changes over time	Drift model or wider uncertainty required
Clock jumps	Segment timeline around discontinuity
No shared anchors	One-way timing is not defensible

Root-cause worksheet

Record host and daemon, configured/server-resolved addresses, capture point, request/reply times, stratum/leap state, RTT distribution, selected peer, daemon offset/frequency/jitter, firewall/NAT/VPN state, boot/resume event, and application symptom.

Potential host causes include VM pause/resume, poor virtual clock source, oscillator drift, overloaded scheduling, disabled daemon, conflicting time services, permission/sandbox failure, or a policy that refuses a large initial correction. Packet reachability alone cannot choose among them.

Verify remediation

Test startup, steady state, sleep/resume or VM migration, VPN transitions, and loss of the preferred server. Require acceptable offset/jitter over time, healthy peer selection, no rejected/unsynchronized responses, and correctly aligned application logs.

Do not expose systems to arbitrary public NTP simply to make UDP 123 work. Use approved authenticated/internal time architecture, rate controls, and monitoring.

Evidence handoff

Include NTP flow, server identity, request/reply cadence, response status/stratum, delay/jitter evidence, missing intervals, capture-clock source, host-daemon logs, and uncertainty. Preserve NTP packets around the application failure and correction event.

Use capture scope help and the packet preparation workflow before sharing. Server names, internal addresses, and exact incident times can be sensitive.

Direct answer: can PCAP prove clock drift?

A PCAP can show NTP exchanges, timing at its capture clock, missing replies, and server status. Host time-service logs and an independent reference are required to prove the host’s offset, frequency drift, and correction policy.

NTP mode and port interpretation

Do not filter only udp.dstport == 123. Client requests commonly use source port 123 or an ephemeral port depending on implementation, and server replies reverse the tuple. Identify NTP mode fields and pair originate/transmit timestamps. NTS-enabled deployments also use TLS-based key establishment before protected NTP exchanges; preserve the configured architecture.

What is a Kiss-o'-Death response?

It is an NTP control response indicating rate or access conditions through reference identifiers such as RATE or DENY. Record the code and client poll behavior. Increasing request rate after a rate response worsens the problem; fix configuration and obey server policy.

What does stratum mean?

Stratum describes distance from a reference clock, not guaranteed quality. Stratum 1 can be reached over a poor path, while a stable internal stratum 3 may be appropriate. Stratum 16 generally indicates unsynchronized state. Combine it with root delay, dispersion, reachability, and daemon selection.

Virtual machine and suspend/resume workflow

Capture from before suspend or migration through resumed synchronization. Record hypervisor clock integration, guest daemon, step/slew logs, and whether two time services compete. A VM can jump due to restored host time while NTP packets themselves remain healthy.

Lifecycle event	Evidence to correlate
Boot	Initial clock, first samples, step policy
Suspend/resume	Wall-clock jump and daemon restart
Live migration	Host clock source and guest offset
Snapshot restore	Duplicate old time/state
CPU starvation	Poll/scheduling gaps and daemon logs

Can two time services fight each other?

Yes. Hypervisor tools, chrony, systemd-timesyncd, ntpd, PTP, or vendor agents may each adjust the clock. Inventory active writers and choose one authoritative hierarchy. Packet captures cannot show a local clock set call.

PTP and hardware timestamp boundary

For sub-millisecond systems, NTP may not meet requirements. Precision Time Protocol and hardware timestamps use different messages and capture semantics. Do not infer PTP quality from an NTP article or software-timestamped PCAP. Record hardware clock, PHC synchronization, and timestamp layer.

Security and authenticity

Unauthenticated time can be spoofed or redirected. Use approved servers, access controls, monitoring, and authenticated mechanisms such as NTS where required. A responding UDP endpoint is not automatically trusted time.

What should the final incident statement say?

“Client requests to approved server X received no replies for 18 minutes at host-side capture; ICMP was absent. The daemon reported loss of reach and offset grew to Y. A second capture is required to locate the missing return path.” Or: “Replies were regular, but the daemon rejected them as unsynchronized stratum 16.” These conclusions assign different work.

Keep raw captures and host logs unchanged. If a corrected timeline is created for review, label it as a derivative and follow the timestamp manifest requirements rather than replacing original packet time.

Monitor both loss of synchronization and excessive correction, because a host can receive packets yet remain outside the application’s permitted time skew.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: