Status file counts sessions, not the LAN behind them
A snapshot lists VPN sessions and routing state, not every machine behind a site. Read the headers, the record types and the file age together.
Someone asks how many machines are on the VPN, and the status file is produced as evidence. It answers a narrower question: how many sessions exist in this snapshot, and which virtual addresses the server routes. The gap between those two questions is where most reporting mistakes live, and closing it starts with reading the file's own headers.
What the snapshot actually contains
The file is written on an interval when status output is configured for that server instance, so it is a periodic picture rather than a live feed. Its sections list sessions and internal routing state separately, and the format version decides the column layout.
status /run/openvpn/office.status 30
status-version 3Version 3 writes tab-separated fields with a header row, while older formats differ and later versions may add fields. Read the header instead of hard-coding a column number, because a script that assumes positions breaks quietly on the next upgrade.
| Record | What it describes | What it cannot tell you |
|---|---|---|
| Client list | A session in this snapshot | How many people or machines that session represents |
| Real address | The outer peer address and port | Which device is behind it |
| Routing rows | Virtual addresses and route ownership | Which downstream hosts are alive |
Count sessions, not people or machines
A single site connection can carry traffic for several authorized machines behind it. A single person can also hold more than one session at the same time, from a laptop and a phone. Neither pattern is visible in the count, which is why connected users is only meaningful once you define the unit. Ask which unit the report needs before anyone starts counting.
If the number matters for licensing or capacity, define the unit in the same document as the report. A report that does not state whether it counts sessions, identities or devices will be read as whichever one the reader expected.
The outer address is not an identifier
The real-address field is the peer address and port as the server sees them. Several clients behind one translated public address share that address, so grouping by it merges unrelated sessions. The port changes between connections as well, which makes the pair useless as a stable key. A report grouped that way looks precise and is wrong.
Use the effective client identity for grouping, and treat the address as transport detail. When two rows share an identity, that usually means concurrent sessions rather than a duplicate record.
Routing rows are not host inventory
A routing entry can name a subnet that one peer is responsible for, and a subnet is not a list of its hosts. The server knows it should send that range to a particular session, and it has no idea which of those machines are powered on, authenticated to an application, or useful to anyone. The routing table describes reachability, not occupancy. That difference is the whole reason a VPN cannot answer an inventory question.
Several rows can also point at the same peer, because a site may advertise more than one range. Counting rows and calling the result a device count overstates the deployment by an arbitrary factor.
If the requirement is genuinely an asset inventory, use the inventory process that owns that network. The VPN can identify which peer carries a route, and that is a different fact from which hosts exist behind it.
Age, permissions and a live view
Keep the file's modification time with every answer. A server that stopped hours ago leaves its last snapshot in place, and a stale file presented as current is worse than no report at all.
The directory has to exist and be writable by the account the service actually runs as, which is easy to forget after a hardening pass. The file usually contains names and addresses, so keep it in an administrative location rather than anywhere a web server can serve it. Check the permissions from the service account, not from your shell. A snapshot that silently stops updating looks exactly like a quiet network.
For event-driven needs, use the supported management interface rather than polling faster. Treat that interface as control, not as metrics, and never expose it across the internet just to count sessions.