tls-auth key-direction: 0 and 1 Must Differ, Not Match
With tls-auth the two ends need opposite directions, 0 and 1, or both must omit the setting. The same number fails, and tls-crypt never uses it.
One side of the tunnel signs the control channel with a key slot the other side never checks, and the connection dies with an authentication error before a single certificate is exchanged. That failure is what a tls-auth direction mismatch looks like, and it is deterministic: the same two files fail on every attempt, from every network. Nothing in the log names the option you are hunting for, which is why people rebuild keys and reissue certificates that were never broken. The fix is to make the two ends complementary, or to leave both of them bidirectional, rather than to weaken verification.
The Failure Lands Before Certificates
With tls-auth, both peers hold the same shared key and each uses one of two slots derived from it: one slot signs outgoing control packets, the other verifies incoming ones. Direction 0 and direction 1 assign those roles in opposite order, so the pair has to be complementary for the HMAC checks to line up. When the assignment is reversed on one side, the receiver looks for a signature in the wrong slot and rejects the packet. The session ends there, which is why the error concerns packet authentication rather than anything the certificate store would produce.
The determinism matters for diagnosis, because a timing or path problem leaves a different signature: intermittent drops, one direction failing, or a session that dies only on a particular network. A direction mismatch fails the first handshake every time, and it fails identically on a different machine holding the same two files. Read the log at --verb 4 and find the first rejected packet instead of the last line. If that rejection happens before any certificate exchange, the shared key and its direction are the two things worth checking.
| What you see | What it rules out | Next check |
|---|---|---|
| Authentication error before any certificate is sent | The data channel is irrelevant; the control channel never authenticated | Compare tls-auth and its direction on both ends |
| Certificate or handshake failure after the control channel authenticates | The shared key and its direction already agree | Check the CA, the certificate dates and the hostname |
| Session completes but throughput or cipher warnings appear | Direction was never the problem | Compare the data-channel cipher settings |
| Startup stops on an options error | The number itself is not the issue | Re-read the inline versus external directive syntax |
Where the Number Lives
The OpenVPN 2.6 manual documents two places for the direction: the second argument of tls-auth when the key sits in a file of its own, and a standalone key-direction line when the key is inlined in the profile. Both set the same value, so a profile should use one form or the other, never both. Omission is also a choice, and it puts both peers into a bidirectional arrangement that works when neither side names a direction. Two peers carrying the same number are not in that arrangement: each expects to sign in one slot and verify in the other, and both do it the same way round.
# server.conf, external key tls-auth ta.key 0 # client.ovpn, external key tls-auth ta.key 1 # client.ovpn, inline key key-direction 1
The inline form is a directive on its own line, not an attribute on the opening tag of the key block, and adding an argument to that tag is an error rather than a direction change. Placement matters as well: the directive sits outside the block it belongs to, so a value written inside the block is read as key material. Copy the arrangement the profile's distributor intended instead of inventing a pairing, because a profile that works against one server may already be mirrored on the other side.
What the Option Leaves Alone
It does not encrypt application traffic. tls-auth puts an HMAC around control-channel packets, while the data channel is protected by session keys negotiated during the handshake, so a throughput or cipher question has nothing to do with the direction number. The setting also adds no second layer of encryption, which is the assumption that sends people hunting for a longer key.
It does not apply to tls-crypt, a different control-channel mechanism with its own options and key handling, and it says nothing about any peer's certificate identity. A working direction match therefore proves only that both ends agree on how to authenticate the control channel, not that the trust chain was validated.
Align the Pair, Then Reconnect
Compare the two configurations before changing either one, because editing the side that was already correct doubles the work. The grep below shows which mechanism each file selects; the verbose run shows whether the control channel authenticated at all. Keep both outputs, so the next change can be compared against a known state.
grep -n -E 'tls-auth|tls-crypt|key-direction' server.conf client.ovpn openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'hmac|tls error|control channel'
Restart both peers after any change, since these options are read once at startup and reloading one side leaves the pair inconsistent for the life of the old session. If the deployment currently works with no direction configured, adding the setting on one peer reproduces the failure you started with; either leave both alone or configure both. Change one end at a time and keep the previous file, so a regression is a two-minute revert rather than a rebuild.
Record the mechanism, the key file and the direction for each end in the deployment notes, because the next person will otherwise read two similar files and assume the numbers should agree with each other. The direction is a coordination detail, not a security upgrade: it separates the two directions of the control channel and does nothing else.