Monitor VPN Peers Without Logging Where They Browse

Monitoring a VPN peer needs four facts, and none of them is a destination. Whether the tunnel is up, when it last exchanged traffic, which keys are involved, and how much moved are enough for availability. Anything beyond that is a record about a person, and it should be a deliberate decision rather than a side effect of opening a status page. Start from the question you must answer, then choose the smallest output that answers it.

Decide the question before the tool

Write the operational question first: is this peer connected, and is it moving traffic? That question needs a live view, and a live view has no retention problem. A second question, whether the peer was connected at 02:00 last Tuesday, needs a stored series and therefore a retention decision. Separating those two is the whole design, because the live view is cheap while the stored series turns into a data-protection conversation.

Keep the health check separate from the status output as well. A recent handshake proves the tunnel negotiated, not that the private application behind it works, so test the application through an authorised check instead of inferring it from counters. When the check fails and the handshake is recent, the problem sits past the tunnel.

Read the three fields that answer it

WireGuard's plain status output carries the interface, public key, endpoint, latest handshake and transfer counters. Presence needs the public key and the latest handshake; if you must, add the byte counters to see movement. The endpoint is not needed for presence and is the first field to drop, because it identifies where a device connects from. The manual page describes each field the tool prints, and it is short enough to read once:

wg show
wg show wg0 latest-handshakes

Read those numbers as ages rather than booleans. A handshake is current only relative to the protocol's own rekey interval, and a counter that has not moved may mean an idle peer instead of a broken one. Keep both in the same view so age and movement are read together.

Pick an interval you can defend

Every status sample is a record, so the interval is a retention decision wearing a monitoring label. A ten-second sample gives fine detail and multiplies the stored rows, while a one-minute sample is usually enough for availability at a sixth of the cost. Choose the interval from the response time you promised rather than from what the tool can do. Then write the number beside the dashboard.

For OpenVPN, the status facility writes a file at a configured interval. In the server configuration that looks like status /var/log/openvpn-status.log 60, where the trailing number is the seconds between rewrites, and the file is replaced rather than appended. That detail matters: a replaced file has no history, while a collector that appends to it creates one.

Confirm that the collector honours the interval as well. A tool that samples every second and stores one row per minute still reads every second.

Keep the labels stable and the mapping restricted

A public key identifies a device relationship even when no name is attached, so treat the key as personal data rather than as an opaque identifier. Label peers with stable internal identifiers that survive reconnects, and keep the mapping from identifier to person in a restricted place. A dashboard that writes a time series is a stored record even when the VPN keeps no file of its own. When the dashboard is the only store, the dashboard is where the retention rule applies.

Review the export path too, because a copied CSV outlives the system that produced it. Aggregate availability is often enough for a report: the proportion of peers with a handshake inside the window answers the operational question without listing who was connected when.

Document what you collect and what you do not

Write the collection description in plain language: which fields, from which interface, at what interval, stored where, kept for how long, and who can read it. Put it beside the runbook rather than in a policy repository nobody opens during an incident. The description should also say what the monitoring cannot see, because that is what stops someone assuming the absence of browsing data means the absence of records.

Review the retention window whenever the monitoring changes, since a new field quietly extends what is kept. Then delete what the description says you delete, and verify that the deletion actually happened.