tls-auth vs tls-crypt: what each protects in OpenVPN

Both options take a shared key file and both make handshake traffic harder to forge, which is why they get treated as two names for the same feature. They are not. One signs control packets, the other encrypts them as well, and neither has anything to do with the cipher that protects your payload.

That distinction matters when a profile fails to connect, when a security review asks what the key protects, and when someone assumes the extra file makes the tunnel encrypted in some undefined way.

What the shared key actually protects

The key used by these options belongs to the control channel: the exchange that negotiates parameters, proves identities, and derives the data keys. It is a pre-shared secret that both endpoints must hold before the handshake can proceed. Because it sits before identity checks, a wrong key stops the conversation earlier than a wrong password would. That ordering explains why the failure mode is so quiet.

tls-auth uses that secret to compute an HMAC over control packets. A packet without a valid signature is discarded before it reaches the more expensive TLS processing, which is why the option is often described as a first filter rather than a replacement for TLS.

tls-crypt goes further by encrypting the protected control traffic as well as authenticating it. Certificate contents, negotiated cipher names, and other handshake details are no longer visible on the wire, and an observer without the key cannot even see which TLS version is being attempted. For a deployment worried about revealing its VPN fingerprint, that property is the main reason to choose it. It is still a group secret, not a per-user credential.

Neither mechanism issues identities. The shared key is a group secret, and everyone who holds it can satisfy that layer of the check.

Where the two options differ

The observable difference is what an observer sees. With tls-auth, the handshake is visible but unverifiable without the key. With tls-crypt, the handshake is opaque to anyone who does not hold the key.

Configuration differs too. tls-auth is used with a direction value, so one side uses one half of the key material and the other side uses the other half. tls-crypt uses a single key in both directions, so the direction directive is not part of its arrangement.

The two options are mutually exclusive in modern releases. A profile should carry one of them, not both, and the server and client must agree on which one, with matching key material. Keeping an old directive next to a new one is common migration residue. Remove the inactive one so the next reader knows which layer is actually in force.

A newer variant, tls-crypt-v2, ties each client to its own wrapped key so that revoking one client does not require reissuing the group key. It is worth knowing about, but it is a different option and not a synonym for either of the two here.

Why a mismatch looks like nothing happens

When the shared material does not match, the peer discards the packets without telling the sender why. There is no authentication error to read, because the packet never reached the layer that would produce one.

The client retries, the server says nothing, and the symptom looks like a network problem. People then restart the service, retype the account password, or remove the protection directive to "test" it, which changes the deployment rather than diagnosing it.

Read the server log for the first packet-level complaint rather than the last retry line. Confirm that both sides carry the same option with identical key material, and that the key file was not regenerated on one side only.

Removing the directive is not a safe repair. It disables a protection layer for every client, and a working tunnel afterwards proves only that the layer was the mismatch.

What still has to be configured separately

These options do not verify who the peer is. Certificate validation, the trust anchor, and the expected server name remain separate requirements, and none of them becomes optional because a shared key is present.

They also do not choose the data cipher. That is a separate negotiation controlled by the data-channel settings on both peers, and a tunnel protected by tls-crypt can still use a cipher you did not intend.

Finally, the shared key itself needs handling. Treat it as a secret, distribute it through an approved channel, and replace it when anyone who held it leaves. Because it is shared, its exposure is the exposure of every endpoint using it.