Which OpenVPN Packets Does the auth Digest Protect?
The auth option covers less than a profile suggests. Walk the channel, the AEAD case and the control-channel protection before you set a digest policy.
Most arguments about OpenVPN digests start from the wrong packet. Reading auth SHA256 as "accept only peers that offer SHA256" is the first thing to unlearn. The option names a digest for particular packets, and which packets those are depends on the channel and on whether that channel is AEAD. Work through the four questions below in order; each one narrows what the setting can mean in your deployment.
Name the channel the setting is meant to protect
OpenVPN has a control channel that carries TLS handshake traffic and a data channel that carries the tunnel payload. The auth digest has a role in both, but not the same role, and the profile rarely makes the difference visible. Write down which of the two you are trying to constrain before you touch a config file.
The table below is the short version of how the same option lands in each context.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Check whether the data channel is AEAD before you rely on it
If the negotiated data cipher is AES-GCM or CHACHA20-POLY1305, the data channel authenticates itself and the separate digest is not doing the work you may be imagining. Both are AEAD constructions, so integrity is produced by the same operation that encrypts the payload. That is not a downgrade, but it does mean a policy justified as "every data packet is HMAC-SHA256" is factually wrong on that tunnel. Confirm the negotiated value in the server log or the client status output before you rewrite the policy.
Inspect the cipher that was actually negotiated rather than the list in the profile, because negotiation can land on a different member of the set. data-ciphers AES-256-GCM:AES-128-GCM is a negotiation list, and both entries are AEAD, so neither of them consumes the auth digest for payload protection.
Treat control-channel protection as its own decision
tls-auth adds an HMAC to control-channel packets and takes its digest from the auth setting, which is why an AEAD tunnel can still have a meaningful digest configured. tls-crypt is a different arrangement with its own fixed protection, so do not assume it inherits every tls-auth property. Read the documentation for the mechanism you chose instead of transferring assumptions between them.
The two peers must also agree on the arrangement and on the key direction. A digest that matches but a key file used in the wrong direction produces a handshake that fails for reasons the digest setting cannot explain.
Keep auth separate from cipher negotiation and certificates
Three settings get conflated constantly: the auth digest, the data-cipher list and the certificate's signature algorithm. Changing the first does not reissue a certificate, does not select its signing digest, and does not create a user-password method. The protocol option definitions in the OpenVPN 2.6 sources describe each in its own section, which is a useful reminder that they are independent knobs.
When a peer refuses to connect after a digest change, the cause is usually a mismatch in one of the other two settings. Read both ends before you change either.
Write the policy down and compare it with running configs
A fleet-level statement should name the permitted data-channel modes and the chosen control-channel protection explicitly, in the same sentence. That sentence is testable; "we use SHA256" is not. Then compare it against effective server and client profiles rather than against a template in a repository.
Finish by recording what each tunnel actually negotiated and which mechanism authenticated its packets. A visible auth line in a profile is evidence of configuration intent only, and intent is the cheapest part of the check.