Shared VPN Account: A Device Limit Is Not Client Isolation

Eight simultaneous connections is a number from a licence page, and it says nothing about what those eight devices can do to each other. A shared login can coexist with per-session keys, and it can also coexist with a gateway that happily forwards one client's traffic to another. Treating the account as a security boundary is the mistake. Ask four separate questions instead: what was bought, what protects the tunnel, what may cross between peers, and what can take the local link down.

What a connection allowance actually promises

A device limit counts how many sessions the provider will accept for one subscription. It is a commercial and operational control, not a statement about identity or isolation. Some providers issue a distinct certificate per device under a single account; others reuse one credential across every connection. The difference appears at revocation time, because separate credentials let you cut off one device and a shared one leaves you no such option.

Read how the provider issues credentials before assuming anything about key separation. The account name itself reveals none of it.

Check whether the gateway forwards between clients

Peer reachability is a server-side decision. On OpenVPN the relevant switch is absent unless it appears in the configuration, but modern data-plane offload changes where the rule is enforced.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

A configuration without that directive leaves peer traffic to the host firewall, which may still permit it. When offload is active the tunnel interface is handled by the kernel rather than the userspace process, so verify rule counters instead of trusting the file. Blocking forwarded traffic between tunnel addresses isolates clients without touching their access to the gateway. Confirm with a probe from one client to a service on another, both before and after the rule.

Protect the session before the peers

Tunnel protection and peer access are different properties, and a strong cipher does not imply isolation. In TLS mode each client derives its own session keys, so one client cannot read another's traffic even when the gateway relays it. A legacy static-key arrangement shares a single key among everyone, which is why reusing a login there has far worse consequences. Inspect the configured mode rather than the marketing page, then judge whether account sharing suits the data involved.

Service authentication on each host still matters, because the tunnel proves only that a client reached the network, not that it should reach a particular daemon.

Local Wi-Fi failures are not VPN compromises

A dropped connection proves that the local link failed, not that anyone broke the tunnel. Interference, a lost DHCP lease and a roaming handoff all end a session without touching credentials or ciphertext. Treat disconnection as an availability finding and keep it apart from confidentiality and peer-access findings. Where the local network is untrusted, protect the traffic end to end rather than leaning on the tunnel alone.

Write the four answers down: allowance, key model, peer policy and local-link dependency. That record turns a vague worry about a shared account into specific controls.