Shared VPN Account Session Limit: Why One Device Drops

You add a second laptop to the account that already runs on your phone, and the phone's tunnel drops within a minute. Or the new device never finishes connecting, and the client ends on a policy message instead of a timeout. The network is fine in both cases; an admission decision was made above it. A shared login is one identity, and most VPN services count that identity rather than the number of devices you own. I work outward from the client screen, which usually shows which layer refused you.

Read the client message before touching the network

Three failures look similar and are not. A timeout means your packets reached nothing. A TLS or certificate error means the endpoint answered but the handshake failed. An authentication or policy rejection means the gateway read your credentials and then declined them. Only the third belongs to a session-limit story, so pin it down first.

OpenVPN clients keep the interesting lines in their log pane. Scroll to the last connect attempt instead of the retry loop that follows it, and look for AUTH_FAILED or a pushed reason string. The client often reports a generic rejection with no explanation, so the next step is the server, not the client's settings. Provider apps are worse: a device-limit message is useful, but a connection that collapses after two seconds is a policy decision, not a bad password. Write down the device name and the exact time either way; an operator can match that pair against an access record in seconds.

Count sessions where the server counts them

The counter that matters lives on the gateway. OpenVPN writes a status file when the server is started with --status, listing every connected client with its common name, real address and traffic counters.

cat /var/log/openvpn-status.log
# or query the management socket directly
echo "status 2" | socat - UNIX-CONNECT:/run/openvpn/server.sock

Two rows with the same common name are two live sessions under one certificate. By default OpenVPN does not keep both: without --duplicate-cn, a second connection using the same certificate replaces the first, and the older device loses its tunnel. That replacement is the signature of an identity limit. Random packet loss does not politely disconnect exactly one device the moment another appears.

WireGuard has no session table to inspect. wg show wg0 prints peers and their latest handshake, and each enrolled device is a peer with its own key. A shared account there is a config file copied onto several machines, and the limit comes from whatever hands those configs out: a provider portal, a seat count, or a rule keyed to your public address. The OpenVPN 2.6 manual documents the server-side options if you run your own gateway.

Separate the four limits that hide behind one message

Most shared-account tickets are one of four admission decisions. The client cannot tell them apart, but the pattern of which device fails can.

Same identity, second connection. The new device works and the old one dies at the same moment. That is a per-identity concurrency rule enforced by the gateway or the account system. Nothing is broken; the service is doing what its policy says.

Seat or device count on the plan. The first devices stay connected and the next one is refused while the others keep running. Check the provider's device list before you change a client, because a licence limit cannot be fixed from the client side.

A cap tied to your public address. Two laptops behind one home router fail while the same login works from a phone hotspot. Move the second device to a different network to test it. If it connects there, you are looking at a per-address or NAT rule, not at the account count.

A server-wide maximum. Everyone on the gateway fails at the same busy hour, including accounts that were fine yesterday. OpenVPN's --max-clients behaves this way, and it has nothing to do with your enrolled devices.

Clear stale sessions before buying more seats

A session that ended badly can still hold a slot. RADIUS accounting writes a record when a session starts and closes it when the session stops; when a client vanishes, the stop never arrives and the server keeps the session until an interim update or timeout expires. On a FreeRADIUS gateway you can see the open records:

SELECT username, acctsessionid, acctstarttime
FROM radacct WHERE acctstoptime IS NULL;

An open record with an old start time and no traffic belongs to a device that is already gone. Close it through the operator's console or with a disconnect request, before you assume the limit was real. Phones reconnect when Wi-Fi hands over to cellular, and a laptop can run one tunnel in the OS plus another inside a vendor app, which counts as two sessions from one machine.

Stop sharing one identity across devices that run together

The durable fix is structural. Give each device its own certificate with a unique common name, or its own account, and record which person and machine holds it. On OpenVPN that means one client certificate per device, with --duplicate-cn left off unless you want takeover behaviour; on WireGuard, one key pair per device, generated there and never copied.

Cloning a profile to get past a device cap breaks revocation: revoking one copy cuts every device that shares it, and the log can no longer tell you which machine did what. If the limit is commercial, the honest fix is an added seat; if it is internal policy, ask for a second identity with the same access rights.

Verify in a fixed order

Test the repair the same way every time, so the result means something.

• Sign out on every device and confirm the server's active list is empty; an entry that will not clear is a stale session, not a client bug.
• Connect the devices one at a time and watch the list between connections.
• If two must run together, confirm both rows carry different identities and both keep their handshake fresh.
• Repeat after a Wi-Fi-to-cellular handoff, since a reconnect can create a second record.

If the old device still drops when the new one connects, the gateway is enforcing a per-identity rule you have not been granted an exception to. Bring the operator the device names, the timestamps and the active-session list; that turns a vague complaint into a policy question they can answer.