Three Clocks in One VPN Log: Client, Gateway, Collector

A VPN incident timeline usually starts with two timestamps that disagree by a few minutes and a display that shows a different hour. The temptation is to pick one as correct and rewrite the other. Both may be right, because they were written by different clocks about different events. The myth is that a VPN has one clock; the work is finding out which component wrote each field.

The myth: the VPN has one clock

A client writes an event when it attempts a connection. A gateway writes an event when it receives or accepts that attempt. A collector writes an arrival time when it receives the gateway's message. Those are three events, and each one is stamped by whichever clock the writing component trusted. Collapsing them into a single timeline is a convenience that hides the disagreement you are trying to explain.

The numbers usually differ by seconds to minutes, and that is normal. What matters is whether the difference is delivery delay, clock offset or a genuinely different event. Deciding which one you are looking at requires the origin of each field, not a stronger opinion about which machine is right.

Read the originator before the value

Before comparing values, identify who produced each one and which field it is. A syslog message carries a timestamp from the originator, as RFC 5424 describes, and the format can also carry time-quality information describing synchronization and accuracy. The same format allows the originator to send no timestamp at all when it cannot read system time, which is itself a useful signal.

journalctl -o short-iso --utc -n 20
logger -t vpn-check "test event"

A client can also send a time value as application metadata, and a service that stores it should label it as client-reported rather than treating it as independently verified. That label is the difference between evidence and a claim. When you export logs for a case, keep the field name, the origin and the offset together. Stripping them to a friendly local time destroys the very information you need.

Stop if you cannot say which component wrote a field. Comparing it to anything else is guesswork.

Timezone display is not a different instant

The same instant rendered as 10:00Z and as 18:00+08:00 is not a discrepancy, and treating it as one wastes an afternoon. Convert both to UTC before you compare, and keep the original text alongside the conversion. A decimal fraction on one side and whole seconds on the other is also not a conflict. Precision is not accuracy: a value with milliseconds can still come from a clock that is minutes off.

date -u +%FT%TZ
timedatectl

Delivery delay is the other ordinary explanation. The gateway records when it accepted the connection, and the collector records when the message reached it, so a gap between them is transport time. That gap says something about the log pipeline, not about the VPN session. Label it as arrival time and it stops competing with the event time.

Correlate without rewriting the evidence

Keep the original timestamps and add a derived column if you need a common view. Explain the conversion in the notes rather than editing the source records, because the source is what a later reviewer will check. Preserve the collector's arrival time separately wherever it exists.

chronyc tracking
journalctl --utc -u openvpn-client@work -n 50 --no-pager

Changing a device clock is not a privacy control and does not rewrite records another system already holds. It also makes support evidence harder to compare, and it can break the certificate and code checks that depend on time. Keep clocks synchronized for ordinary operation, and treat any deliberate skew as a fault to investigate. If the two records seem out of sequence, look at clock sync and delivery before you construct a new history.

The myth to retire is that there is one VPN time. Ask what wrote each field and what happened when it did, and the timeline becomes a set of labelled observations rather than a contradiction.