OpenVPN packet HMAC Authentication Failed: Which Layer?

Two failures get reported with the same vocabulary and have almost nothing in common. One is a packet whose authentication tag did not verify; the other is a person whose credentials were refused. Treating the first as the second sends you hunting for a password that was never the problem.

The message names a layer, and the useful work is deciding which layer before replacing any material. Comparing the candidates side by side is the fastest way to see the difference.

Two failures that share a word

A packet-authentication error is raised while processing traffic: a tag or digest on a received packet did not match what the receiver computed. An account rejection happens after a login exchange has been parsed, and it names a user rather than a packet. A third message, about being unable to locate an HMAC in an incoming packet, is different again, because there the packet arrived without the expected authentication element at all. The full log prefix tells you which of the three you have, and the prefix is usually the first thing removed when an error is pasted into a ticket.

The distinction changes the repair. One calls for matching channel settings, another for account state, and the third for a profile that does not match the listener it reached.

Compare what the running process actually loaded

A correct file on disk proves nothing about a process that started before it was edited. Check the selected profile, the endpoint it contacted, and whether the service has been reloaded since the change. Confirm as well that the endpoint belongs to the profile, since another instance or another service can be listening where the old file expects something else.

Re-exporting a supported profile from the same source is a cheap comparison, because it removes drift between what you believe is configured and what the client actually sends. Generating fresh key material is a much larger step, and it only helps if both ends adopt it together. Replacing one side locally recreates the mismatch you were trying to remove.

Compare the control channel with the data channel

Two mechanisms authenticate different parts of a connection and are configured separately, as the 2.6 option reference describes. tls-auth adds an HMAC to control-channel packets and takes a direction argument that must be opposite on the two peers, while tls-crypt protects the control channel with a shared key instead. Neither is the data channel's own integrity check. With an AEAD data cipher that check is built into the cipher, so the separate auth digest is not used the way it is with a non-AEAD cipher.

Which means an auth line copied from a working non-AEAD deployment can be irrelevant in an AEAD one, and an AEAD deployment can still fail on the control channel if the tls-auth key or its direction is wrong. Compare each setting against the peer rather than against a remembered configuration.

Compare the fix with the property you give up

Disabling packet authentication silences the warning and removes the check that found the mismatch, which is not the same as repairing the profile. Ask which property you are surrendering and whether the design still holds without it.

Read the first relevant event on both ends before changing anything, then change only the mismatch it names.

If the next attempt progresses to a certificate or login error, that is progress rather than regression: the packet layer now agrees and the connection has moved on. Record the settings that produced the change, so the next person inherits an explanation instead of a mystery.