VPN Connection Limits: Live State vs a Retained History
A three-connection limit needs live slot state, not a browsing history: what the mechanism must store, what it can discard, and where that state goes next.
Three simultaneous connections is an admission decision, and answering it requires knowing which slots are occupied right now rather than what happened last month. A service can refuse a fourth session from a small table of active records and never build a timeline at all. That is a statement about the mechanism, not about the operator, and the difference matters when you read a privacy policy. The model below shows what the decision needs and what it can discard.
The mechanism: a slot table, not a log
The simplest implementation associates a subscription with up to three active session records. Each admitted session takes one slot, and the slot is released when the service decides that session has ended. The record needs an identity specific enough that releasing one connection does not free another connection's slot, which is why the session identifier matters more than the account name.
Occupancy and history are different data structures. Occupancy answers a yes-or-no question about the present, and it can be discarded the moment the session ends. A history is an append-only stream of events, and it survives because someone chose to keep it. A service can have either, both or neither.
The distinction is invisible from outside. A visible connection limit is compatible with a tiny in-memory counter, a shared database table, and a full event archive with a dashboard. Nothing about the limit tells you which one is running.
| What is stored | Why it exists |
|---|---|
| Active session slots | To admit or refuse the next connection |
| Session event log | To investigate or bill later |
| Monitoring series | To watch capacity and error rates |
| Backup copies | To restore any of the above |
Why the live model still needs coordination
A lost connection may not be recognised as ended straight away. The gateway waits for a timeout, a keepalive failure or an accounting stop, and until one of those arrives the slot stays occupied. A user who reconnects during that window sees a refusal that has nothing to do with a fourth device.
A restarted server has to reconcile its state, and several gateways serving the same account need a common decision. Otherwise an account can exceed its allowance by connecting to different locations. Shared or recoverable state solves that, and shared state is a design requirement rather than evidence of surveillance.
None of that coordination requires browsing histories. A gateway that forwards packets does not need to know which sites a session visited in order to count sessions, and the two data flows are usually handled by completely different components.
Keeping a count in memory does not make the associated facts anonymous either. While the service runs, a subscription-linked record reveals that an account has active connections, and access to that state plus its lifetime are both worth asking about.
Where the state goes afterwards
The privacy question is not whether the server can count. Ask what happens to an ended session: is the record removed, or does it become an event in a monitoring series? Then ask which other components saw the same event, because authentication logs, accounting records and backups can each keep a copy that the enforcement path discarded.
RADIUS accounting is the clearest example. A Start and Stop pair exists to support billing and session control, and it creates a record of the connection regardless of whether anyone ever queries it as a history. A service that enforces limits through accounting therefore retains more than a slot table by construction.
Deletion also has a shape. A record removed from the live table can persist in a backup taken an hour earlier, and the retention period of that backup is its own policy statement. Reading only the primary store gives an incomplete answer.
Ask the question in terms of fields
RFC 6973's data-minimization guidance ties the data collected and stored to the purpose being served. Applied here, the useful question is which fields the concurrent-admission task actually needs, and what purpose justifies keeping each one after that task ends.
A precise service statement separates live connection state used to enforce the allowance from any records retained after termination, and it names the other systems inside the promise's scope. A sentence that says only that three connections are enforced establishes neither that an archive exists nor that none does.
When the lifecycle is unclear, record it as an unanswered retention question rather than a verdict. The presence of a limit is not evidence of a hidden history, and a plausible live-state explanation is not an audit of the provider.