Why only one VPN client connects behind the same router

Two laptops sit on the same home network, and the office VPN accepts exactly one of them. The second either times out or waits until the first disconnects, and nobody touched a client setting between the two attempts. The credentials are the same ones that worked a minute ago, which is the clue that authentication is not the failure. Three mechanisms produce this pattern, and the server's own log says which one you are facing.

Read the gateway log before you touch a client

The server's record of both attempts answers the first question, and it answers in one of three ways. If the second attempt never appears in that log, the packet never reached the listener, and the home router or the provider's path owns the problem. If the log records an attempt and rejects it, the tunnel arrived, so the issue is identity, licensing or a session cap rather than anything on the wire. If the log records a successful session while the client still reports failure, look at the return path or at two clients being handed the same tunnel address.

A phone hotspot separates those families cheaply: run the second client over mobile data while the first stays connected. Success there implicates the home network, and the same failure there implicates the gateway, which leaves the router innocent. Neither result is conclusive alone, but each eliminates half the search space in one attempt.

Write the outcome down before changing anything, because the three log outcomes lead to three unrelated repairs. A note naming which of the three you saw is worth more than a screenshot of a client error.

What the router does with GRE and NAT-T

PPTP is the classic offender: the control channel is TCP 1723 while the data path is GRE, IP protocol 47. Many consumer routers ship a PPTP helper that tracks a single control connection, so a second client behind the same NAT opens its control channel and then receives no data path at all. Forwarding a TCP port numbered 47 does nothing for GRE, because GRE is a protocol number rather than a port.

L2TP over IPsec behaves differently by design: IKE uses UDP 500, NAT traversal moves the protected payload to UDP 4500, and the encapsulation exists precisely so several clients behind one address can reach the same gateway. That design does not prevent a gateway or an intermediate middlebox from imposing a per-address session limit, and from the sofa the two failures look identical. SoftEther's native protocol has the same class of problem, where a router without working pass-through admits the first client from the LAN and drops the second. Test the router's ALG or pass-through switch in both positions, since a helper written for an older client can corrupt packets that a current one sends.

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

Identity caps that look like transport caps

The router is not the only suspect, and the log distinguishes it from the alternative. When an OpenVPN server pins a common name to one tunnel address, both devices receive that address, and without duplicate-cn the newer session pushes the older one out. Enabling that option lets both stay connected while leaving them with one identity, one certificate and one revocation decision, which is worse than it looks. The second device can then never be revoked on its own, so a convenience switch quietly removes a control you may need later.

Read the server's journal and its status file together, because one shows the authentication decision and the other shows who is currently connected. Two entries sharing a common name and a virtual address confirm an identity collision rather than a router limit. Commercial gateways add caps of their own, such as a plan allowing one concurrent session, a licence count, or a rule permitting one session per public address, and no router setting changes any of those.

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

Match the repair to the log entry

A rejection in the log calls for separate credentials per device, a higher limit from whoever runs the service, or a second gateway endpoint for one machine. If no second attempt ever reaches the server, the lasting repair is a router that forwards the protocol and holds more than one session, or a transport the router handles well, such as a single TCP or UDP flow. Choosing between those is a decision about hardware lifetime, not about client settings.

Do not copy a working device's profile onto the second machine and call it done. That converts a connection problem into an access-control problem, because a lost laptop can no longer be told apart from the copy still in use. It also hides the original fault, which returns the moment a third device appears.

Verifying two live sessions

Connect both devices at the same time, run the intended application on each, then reconnect one of them and repeat. A second icon that appears briefly proves nothing about traffic, and a session that drops after ten minutes is a different bug with a different owner. Compare what the server reports at the end against what the users saw, since those two accounts often disagree.

If both sessions survive and carry traffic, the fix holds and the note you wrote at the start becomes the record of what was wrong. If only one survives, return to the first step and check which of the three log outcomes you now have, because the answer may have changed. Router helpers can mask a problem that reappears on a different network, while a per-address cap follows the user rather than the device. Testing from a second network is the cheapest way to find out which of those you actually fixed.