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.