OpenVPN compression: refuse, receive-only or full LZO?
comp-lzo no is not a strict refusal. Compare refusing compression, accepting it one way during migration, and keeping it, then check what offload does.
Three lines in a profile look like they all turn compression off, and only one of them actually does. The difference matters because the warning you want to silence is a symptom, while the policy is what decides whether a peer can still compress. Comparing the options on a single axis, what each one permits after the change, removes most of the ambiguity. Which one you want depends on whether you are migrating or settling.
Three policies that look similar in a config file
Each option answers a different question. allow-compression no refuses compressed payloads outright, allow-compression asym decompresses what arrives and never compresses what leaves, and the legacy comp-lzo no leaves room for a peer push to enable compression. Only the first is a policy a server cannot override.
Write the three into a table before choosing, because the names are close enough to mislead a reviewer. Two of them still run decompression code on received packets, which is the part the security argument is about. The third removes the capability rather than restricting its direction. If the change record says compression is disabled, exactly one row satisfies that sentence.
The warning that started the investigation is not the objective. Silencing it while leaving a permissive policy in place yields a clean log and an unchanged exposure.
| Setting | What it permits | When it is the right answer |
|---|---|---|
allow-compression no | No compressed payloads, and no compression framing under offload | Both ends can be changed now |
allow-compression asym | Decompress inbound only | A dated migration while peers catch up |
comp-lzo no | Off locally, still pushable by a peer | Legacy compatibility you can still justify |
What no means on the old LZO option
On the deprecated LZO option, no disables compression for the local side without forbidding a peer from enabling it where policy allows. That asymmetry is why moving a profile to a strict refusal changes behaviour in ways a single-server lab test may never reveal.
The security concern is conditional rather than absolute. When an attacker can place chosen plaintext beside a secret and watch how compression changes the size of encrypted traffic, an information channel exists. Switching from LZO to LZ4 changes the algorithm and the framing, not that mechanism.
So the honest framing concerns what you are willing to permit, not which algorithm is currently recommended. Strict refusal is the only option that does not depend on the other end's cooperation.
Receive-only is a migration state, not a destination
Asymmetric acceptance exists so one end can stop compressing while the other still expects to. It is a bridge, and bridges need an end date and an owner. Record which peers are still sending compressed traffic, because the policy permits exactly that traffic. Without that list, the migration state becomes the permanent configuration by inertia.
A client cannot force an incompatible server to abandon old framing by editing its own file. The push direction is decided on the server, so the server configuration and its per-client files are where the migration actually finishes.
Stub modes preserve framing while skipping the compression work itself, and they are not a drop-in equivalent of the older option. Test them against the oldest peer you still have to support before committing to one.
Where data-channel offload changes the answer
Data-channel offload moves packet handling into the kernel, and a profile that still depends on compression framing may not fit the offloaded path. The failure is not always loud: a client connects and then behaves differently from the tunnel you tested.
Check which implementation is active before and after the change, not only whether the connection succeeds. When the offloaded path refuses compression framing, a strict refusal policy and an offloaded deployment agree, while a permissive policy and an offloaded deployment do not.
That combination deserves its own test, since it is exactly where a file that looks correct is silently not the one in use. Compare the negotiated state against the intent recorded in the profile, because only one of them is visible in a log.
Pick a policy, then verify the negotiated result
Choose strict refusal when you can change both ends, asymmetric acceptance when you cannot yet, and full compression only when you can state why the exposure is acceptable. Then verify what was negotiated rather than what the file says. A quieter log is evidence only when it matches the policy you intended to deploy.
Keep the decision next to the profile it applies to, with the date and the peers still exempted. Six months on, that note is the difference between a deliberate exception and an accident nobody can date. Write it in the same repository as the profile so the next editor sees the reason before the directive.