Why an encrypted VPN packet can cost less than you think

Two profiles get benchmarked on the same gateway, one with encryption and one without, and the encrypted one is not slower. Sometimes it is faster, which usually produces a long argument about whether the test was run correctly. The result is plausible, because the cost of a packet is not the number of cryptographic words in the configuration. It is the set of operations the implementation performs, on the hardware it has, over the buffer layout it chose.

The symptom: the encrypted profile is not the slow one

Suppose a historical test compares an AEAD cipher against a "no encryption" mode that still computes a separate authentication code per packet. The second profile hides payload contents but keeps a per-packet hash, and on a processor without acceleration for that hash it can cost more than the integrated construction it was meant to beat.

The label in the configuration says "encryption", and the label is all most comparisons look at. The packet path says something different: one profile performs a combined operation the CPU has instructions for, and the other performs a separate one it does not. Reading the configuration file alone will never reveal that difference, because both entries look like one line. Only the negotiated mode and the code path behind it explain the result.

That is the whole explanation, and it does not require any claim about which primitive is universally faster. Both can be fast, both can be slow, and the ordering depends on the machine and the code.

Count operations, not labels

An AEAD construction, as described in RFC 5116, gives the implementation a single interface that returns ciphertext and a tag together. AES-GCM is one instance: counter-mode encryption combined with a Galois authenticator. The interface does not make integrity free; it makes the combination well defined, which is what allows an implementation to optimize the pair as a unit.

Separate authentication path:
  payload -> independent HMAC -> framed packet

AEAD path:
  payload -> authenticated encryption with tag -> framed packet

Those are processing sketches rather than configuration advice. The first has no confidentiality but still spends CPU on authentication, which is exactly why "turn off encryption" is not a synonym for "turn off cryptographic work".

The second can be cheaper because processors provide instructions for both halves: AES rounds and the carry-less multiplication the Galois field uses. Libraries also process independent buffers in parallel, which keeps those instructions busy instead of waiting on memory.

What the negotiated mode actually enables

With Community OpenVPN, an AEAD data cipher means the auth option no longer contributes a separate data-channel HMAC of its own. The encryption option reference describes that scope, and it is the reason two configurations that look similar in a text file can differ in per-packet work.

Read the negotiated mode rather than the wish list. A permitted cipher list and a TLS suite name do not tell you which operations run on the payload, and a legacy cipher line may not describe what the current connection chose.

openvpn --show-ciphers | head -20
sudo grep -E 'cipher|auth' /etc/openvpn/server.conf

The first command lists the ciphers the binary supports, which is a capability list rather than the negotiated result. The second shows what the server actually asks for. The connection log is the place to confirm the final choice, because a client can fall back to something the server permits but nobody intended.

Measure the workload you actually run

A cryptographic microbenchmark measures a primitive under its own conditions. A VPN transfer also copies buffers, schedules threads or interrupts, checks policy and crosses the network. Those parts often dominate, which is why a faster primitive does not always produce a faster tunnel.

openssl speed -evp aes-256-gcm
openssl speed -evp sha1

Those two commands give you a rough local comparison of the primitives on the machine in front of you, and they are honest about being microbenchmarks. They say nothing about your tunnel's throughput, and they should never be quoted as one.

Then measure the workload that matters, with everything else held constant: same endpoint, same packet sizes, same transport, same compression policy. If the profile change also altered transport or processing location, the result describes that bundle rather than cryptography.

Keep the objective in view as well. A data path with spare cryptographic capacity can still be latency-bound because the application waits on round trips, and bulk capacity gains do not fix a chatty protocol. Measure the supported, policy-approved configuration as a whole, and treat "fewer boxes must be faster" as the hypothesis it is. The useful question is not whether encryption costs something, but whether the cost shows up in the measurement you actually care about.