Two devices, one OpenVPN certificate: the reconnect loop

A tunnel that comes up and then restarts every half minute is not usually a cipher or MTU problem. It is one identity being used twice. The server sees a familiar common name, takes the new session as the latest one, and the older device discovers it has been replaced. From the client side that looks like an inactivity timeout and a restart, which is why the investigation so often begins in the wrong place.

Start from the restart interval

The interval is a clue before anything else. A steady cadence that matches the ping-restart window points at a session being replaced rather than a failing path, because path failures are rarely that regular. Note the exact gap between restarts and the reason line in the client log. A timeout followed by a restart tells a different story from a failed handshake.

Check when the restarts began relative to a second device. A new laptop, a phone, or a profile copied to a spare machine are the usual triggers, and the timing usually matches the day someone set it up.

Write the interval and the reason down. Both are evidence, and both are cheap to collect.

Read what the server said about the second login

On a server you control, the log names the common name and shows a second connection arriving. Without duplicate-cn, that arrival replaces the existing session for the same name, and the message usually says so plainly. With duplicate-cn, both sessions coexist and the symptom changes: the clients stay up but share one set of per-client settings and one revocation decision. Read the two entries together, since the replacement is only visible in sequence.

On a hosted service you may have no server log at all. The clue is then timing: a stable tunnel that drops whenever another machine connects, with nothing in the client log beyond the timeout.

Compare the certificate and key blocks in both profiles, not just the remote hostname. Copied profiles usually differ only in the file name.

Split the identity on the server side

Issue one certificate per device through the CA that signs for this server. With Easy-RSA that means a separate client name for each device, and the profile is then built from that certificate and its key. The common name becomes the device identity, which is exactly what the server was missing. Name them for the device rather than the person, so a replacement produces a new name.

The shared control-channel key is a separate thing. tls-crypt or tls-auth protects the control channel for every client and is meant to be shared. It is not a client identity, and replacing it will not fix a duplicated certificate.

Keep the certificate, the key and any per-client configuration file named after the same common name, or the mapping breaks at the next connection. A mismatch there produces a client that authenticates and then receives nothing.

Keep addresses and settings aligned after the split

Fixed addresses introduce a second way to collide. If the server assigns them through ifconfig-pool-persist or a per-client file, those records still point at the old name. Two devices can end up with the same tunnel address even after the certificates are separate, and that failure looks different from the original loop.

Update the mapping at the same time as the certificate, then reconnect both devices and compare their assigned addresses. A duplicate address shows up as intermittent loss rather than a clean reconnect.

Push settings that should differ per device through that device's own file, not through a shared template. A shared template also makes the next duplicate harder to spot.

Retire the old identity properly

Revoke the certificate when hardware is retired or missing, instead of deleting the profile from the old machine. Revocation produces a new CRL, and the server needs that file where crl-verify points. With that directive in place, a missing or unreadable CRL makes the server reject every client, so test one known account after each update.

Keep an inventory that ties each certificate to a person or device, with issue and revocation dates. That inventory answers who still has access without reading filenames, and it keeps the next copied profile from restarting the loop.