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

Time synchronization failures create strange secondary problems: TLS certificates appear invalid, logs are out of order, Kerberos fails, database replication complains, distributed traces are misleading, and cameras or recorders show wrong timestamps. Users search for "NTP clock drift pcap", "time sync failure packet capture", "NTP no response UDP 123", "NTP offset delay jitter", and "why is server time drifting" when system time looks wrong but they need network evidence.

A packet capture can show whether NTP requests leave, whether responses return, which server answered, how often the client polls, and whether network delay or packet loss may affect synchronization.

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:

1. Filter UDP port 123.
2. Identify configured NTP servers.
3. Check whether requests leave.
4. Check whether responses return.
5. Inspect response timing.
6. Look for ICMP unreachable.
7. Compare internal vs external NTP.
8. Preserve NTP packets when trimming larger traces.
9. Correlate with system time-sync logs.
10. 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.