What Counts as a Successful VPN Login in a Report?

Three reports about the same VPN can disagree without any of them being wrong, because each one means something different by a successful login. One counts connections that reached the server, another counts identities the authentication step accepted, and a third counts sessions that finished initialisation. Picking one before collecting data is the difference between a metric and an argument.

The useful question is not which definition is correct in general, but which outcome the reader is going to act on.

Three Different Events Wear the Same Label

A server accepts a transport connection as soon as the handshake completes, which happens before any credential is presented. That event tells you the port is reachable and the network path works, and it tells you nothing about who connected. Authentication is a later step that can fail, and it can also succeed for an identity that is never permitted onto the network.

Initialisation comes after authentication, and a tunnel that finishes initialising can sit idle for the rest of the day. An application request is the only event that demonstrates a user reached something they wanted. These stages nest, so a count of the widest one will always exceed a count of the narrowest. Nothing in the sequence of events proves the user was productive, only that each gate opened in turn.

Product documentation usually names the states explicitly. The OpenVPN management interface notes separate the TCP connection, the authentication result and completed initialisation, which is exactly the distinction a report needs. A state labelled connected does not certify that a file share or database operation later succeeded.

Count Sessions, Identities or Requests

Decide the unit before deciding the number. A session count answers how many times the service was used, an identity count answers how many distinct accounts appeared, and a request count answers how much work was done. Vendors count these differently too, and an entitlement measured in users cannot be compared with a graph measured in sessions. Choosing the wrong one is how a capacity plan ends up sized for the wrong quantity.

Reconnects are where session counts quietly inflate. A client that drops every few minutes and reconnects produces dozens of session records for one person, so a report that counts sessions as people will overstate usage in exactly the conditions where reliability is worst. Write the rule down: a new session after a reconnect counts separately, or it continues the previous one within a defined window.

Addresses are the weakest identity available. A tunnel address can be reassigned to another user minutes later, and two users can share one address through translation. Attach the account identifier from the authentication event rather than inferring a person from an address in a log.

Test the Definition Against One Real Day

Take a single day of logs and count the same traffic three ways. If the three numbers are close, the definition may not matter much for your purpose; if they differ by a large factor, the report needs to say which one it uses.

journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Initialization Sequence Completed"
journalctl -u openvpn-server@server --since "2026-10-01" --until "2026-10-02" | grep -c "Peer Connection Initiated"
awk '/VERIFY OK/ {print $NF}' /var/log/openvpn-server.log | sort -u | wc -l

Run the same extraction on a day with a known outage and compare the shape rather than the total. A day when the uplink flapped should show a spike in connection events with a modest rise in distinct accounts, and if it does not, the counter is probably measuring something other than what the report claims.

Keep the query itself alongside the result. Anyone can reproduce a documented filter, and a number without its filter is not auditable.

Report What the Event Establishes

A failed attempt deserves its own category instead of being folded into either side. Failures include mistyped passwords, clients with an outdated profile and deliberate probing, and the three have different responses. A failure is not evidence of a successful intrusion, and it is not evidence of harmlessness either.

Write the conclusion at the strength the event supports: this account authenticated to this service in this window, from this source, and the session reached initialisation. Anything about what the user then did requires an application-side record rather than more tunnel data.

When the report goes to someone who will make a licensing, capacity or security decision, put the definition in the first line rather than a footnote. The definition is the finding, and the number only makes sense inside it.