What a VPN log can and cannot prove about browsing

Before you pick a log collector, decide which event the audit has to establish. Asking which VPN session contacted a destination address is a different question from asking which person opened a particular page. The two require different records, different joins and different levels of confidence. An OpenVPN connection log answers the first and cannot answer the second.

Name the event before choosing a collector

A session record shows an accepted identity, a start and end time and an address the server assigned under its own policy. A resolver log shows that a name was queried at that resolver. A flow record shows addresses, ports, protocol and time, and an application log shows the transaction that application actually handled. None of those four is a substitute for another.

Each of those establishes one event and leaves the others open. Writing the question down first stops you from assembling a story the data cannot support.

journalctl -u [email protected] --since today | grep -i 'peer info\|assigned'
cat /etc/openvpn/server/openvpn-status.log | head -20
conntrack -L -p tcp --dport 443 2>/dev/null | head -20

The first command shows session events from the service journal. The second prints the current client list with assigned addresses, which is the mapping an audit join depends on. The third shows live flow state, useful only while the connection still exists.

A lookup is not a visit

A browser resolves names speculatively, caches answers and reuses them without asking the monitored resolver again. A name in a resolver log therefore proves a lookup, not a visit. DNS over HTTPS widens that gap, because a browser configured for it sends its questions somewhere your ordinary logger never sees.

Destination addresses are no better on their own. One address can host many unrelated sites, reverse DNS is a guess rather than a reconstruction, and a hostname visible during a TLS handshake is not the request path inside the encrypted session.

For exact transactions you need the application's own event records or a proxy design that is explicitly supported for logging. A CONNECT tunnel gives a proxy the destination and the volume, not the page paths inside it. Administrative access to the network is not a licence to replace the application's trust model quietly.

Join identity and time before you name a person

A flow record carrying an internal source address means nothing until that address is joined to a session at the same time. Addresses get reused, and the same address may have belonged to a different session an hour earlier. Static assignment is one way to keep the association, not the only one.

Translation boundaries weaken the join further. If several devices already shared one source address before your observation point, the best you can identify is the shared gateway session rather than a single device. A certificate or account used by several people has the same effect.

Record time zones, clock sources, observation points and every translation hop. Missing records can mean a flow entry aged out, a sensor that was bypassed or an application log that was switched off. Absence is not proof that nothing happened.

Then define the minimum fields, the permitted readers and the retention period for the stated purpose. Correlation and misattribution are design concerns rather than afterthoughts, and metadata that identifies people deserves the same protection as the identity mapping it depends on.

Test the audit with activity you control

Generate permitted traffic whose session and application you already know, then check what each record actually captured. Run a lookup without loading the page, load a page from cache, and open a connection through a proxy, and see which events appear.

Report the event the evidence supports and say what it does not cover. A modest record with a stated scope survives review; an ambitious browsing history assembled from guesses does not.