duplicate-cn Gives Two Devices One Identity, Not Two

Copy the profile to the tablet, connect, and the laptop drops off. Add duplicate-cn, both stay connected, and the problem looks solved until the two devices fight over the same tunnel address or one lost tablet takes the whole account offline. The option changes one thing and one thing only: whether the server permits a second session under a name it has already seen. Everything people expect it to fix, from device independence to per-device addressing to selective revocation, is still done by identity, and identity here is the certificate.

The myth: a second session is a second identity

The intuition is that two connections must be two clients, and two clients should be two devices with their own rights. The server does not model it that way. It sees a common name, and with duplicate-cn enabled it accepts more than one live session carrying that name, each getting its own session state in the daemon.

Nothing about that acceptance touches certificate verification. The same certificate is still the credential, the same key is still the private key, and any policy keyed on the certificate subject still resolves to the same value twice. A second session is a second socket, not a second identity.

That distinction is invisible while everything works. It becomes very visible the moment you need to tell the two devices apart, which is usually the day one of them is lost.

What really changes when two sessions share a name

Without the option, a new connection under a common name that is already connected displaces the earlier session. That is why the laptop drops when the tablet connects, and it is a deliberate ambiguity guard rather than a bug. With the option, both sessions stay alive and the server tracks them separately by session, not by device.

Each session still gets its own outer connection and its own negotiated keys, so concurrent throughput really is concurrent. What they share is everything derived from the credential: policy lookups, client-specific configuration, log identity and revocation. Session state belongs to the connection and dies with it, while the credential-level facts persist across both. That is why the status output can list the same name twice while the counters stay separate.

Confirm what your build actually does before designing around it, because the option's effect is defined by the option itself and not by folklore:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

The static address you thought you assigned

Per-client configuration is looked up by name, which is the trap. A client-config-dir file named after the common name applies to every device using that name, so an ifconfig-push inside it hands both devices the same tunnel address. The second session either fails to establish or collides in a way that looks like a routing fault.

A dynamic pool behaves better by accident, because each session is allocated an address from the pool independently. That still does not give you a stable per-device address, and it certainly does not give you a per-device policy attached to that address.

If the deployment uses username-as-common-name, the lookup key becomes the authenticated username instead of the certificate subject, and the same collision follows for anyone who logs in twice. The name that drives configuration has to be unique per device for per-device configuration to mean anything.

What a shared identity cannot do at removal time

Revocation operates on the certificate, not on the display name and not on the session. Revoke that certificate and every device holding a copy loses access at once, including the one sitting in the office that nobody wants to disturb. Keep it and the lost device keeps working, because nothing in the protocol distinguishes it from the approved copy.

Logs inherit the same ambiguity. The status output shows a common name and a real address, and both can belong to either device. An incident review that needs to know which machine did what cannot answer the question from the VPN's own records, no matter how much detail the log level provides.

There is no cryptographic workaround for this. Two devices that present the same certificate are, to the server, the same participant twice, and any scheme that pretends otherwise is a naming convention rather than a control.

When sharing is right, and how to bound it

Sharing has legitimate uses: a lab account used by several test machines, or a household where the devices are managed together and revocation granularity does not matter. In those cases, enable the option deliberately, keep the shared credential out of per-device policy, and give the pool room so sessions cannot collide on an address.

For anything that needs separate addresses, separate logs or separate removal, issue separate certificates through the normal enrollment path. That gives every downstream system a distinct object to key on, and the option stops mattering because the names are already unique.

Whichever path you choose, test the management model rather than the login. Connect both devices, confirm they hold different addresses, then simulate a loss and check that you can remove exactly one of them. The openvpn(8) manual defines the option's scope; your removal procedure defines whether sharing is actually acceptable.