Can a static-key OpenVPN link serve several clients?

Static-key mode connects exactly two peers, and that is its design rather than a limitation someone forgot to lift. client-to-client is a server-mode forwarding option, so adding it to a --secret configuration changes nothing about how many clients can connect. The decision is not which flag to add, but whether the deployment needs a point-to-point link or a multi-client service. If several devices must connect independently, the protection mode changes and each device gets an identity.

Two peers, one key, and no per-client state: that shape is the whole story of the mode.

What static-key mode is for

In secret mode both peers share one key file, and that key protects the traffic directly. There is no handshake, no certificate exchange, and no per-client session, because there are no clients in the server sense, only two endpoints.

The mode remains useful for a fixed pair of machines with a documented key rotation process, and OpenVPN 2.6 marks it deprecated precisely because TLS mode covers those cases with better properties. What it cannot do is distinguish one connecting device from another, since possession of the file is the entire authentication story. Adding a third device means sharing the same key with it, after which the first two can no longer tell it apart from themselves.

That is why the two-peer limit is structural rather than a setting to change.

Why client-to-client is not the missing piece

client-to-client controls whether connected clients may exchange traffic through the server. It does not admit clients, assign identities, or create a server mode that was not configured, and in a static-key configuration there is no client list for it to govern.

The other common confusion involves tls-crypt or tls-auth material. A TLS server can share one of those keys across all clients, because it protects the control channel rather than proving who each client is. A shared control-channel key in TLS mode is a different object from a shared static data key, even though both arrive as files that look similar.

Choosing between the modes comes down to two questions. Does more than one device need to connect independently, and does the deployment need per-device revocation? A no to both keeps static-key mode viable; a yes to either points at TLS. There is no third option where a second client is admitted without its own identity.

Building the multi-client server

A multi-client server needs TLS mode, a server-side certificate, and a per-client identity. The server helper sets up the address pool and the multi-client mode, but it does not supply the TLS configuration, the trust anchor, or the client certificates that make admission meaningful.

Enroll each device through the existing certificate authority rather than copying one client's credentials. Distinct identities are what make revocation, per-client routing, and useful logs possible, and a single shared client certificate collapses all three.

If the deployment authenticates users through an external directory or a second factor, that design stays as it is. Moving to TLS server mode decides how peers prove themselves at the tunnel layer, and it does not dictate the account backend. Keep the two decisions separate so a change in one does not silently alter the other.

Then decide the forwarding policy deliberately. client-to-client enables client-to-client traffic in the user-space server path, which many deployments want and some must not have. It is a policy switch, not an identity mechanism, and it should be turned on because the design requires it rather than because a tutorial included it.

Checking that clients are really independent

Connect two clients and confirm they receive different addresses and appear with different identities in the server's log. Then revoke one and confirm the other keeps working, which is the practical test that identities were not shared.

Test the permitted peer-to-peer service and one that should remain blocked. Two successful logins prove admission, not isolation, and the difference matters when the deployment is supposed to separate groups of users.

Finally, read the server mode from the running configuration rather than from memory. A static-key configuration with extra options is still a point-to-point link, and a correct TLS server is the only arrangement in which several clients are genuinely separate peers.

If the log shows one common name for every device, the mode is not the problem. The enrollment process is.