Migration from 2.5.x to OpenVpn 2.6.4 error

Markco

Hello,

I migrated from version 2.54 to 2.64 and I have a connection error:

Compression or compression stub framing is not allowed since data-channel offloading is enabled.
OPTIONS ERROR: server pushed compression settings that are not allowed and will result in a non-working connection. See also allow-compression in the manual.
ERROR: Failed to apply push options
Failed to open tun/tap interface

How to fix the problem

Thanks

Marco

Sorry, I use a French/English online translator

Fadim

The error you're facing seems to be related to the compression settings being pushed by the server, which aren't compatible with your client settings. It's a known issue that's been tightened up in more recent OpenVPN versions to avoid misconfigurations.

The fix involves adjusting your client's OpenVPN configuration file. Please add the following two lines to your configuration file:

comp-lzo yes
allow-compression yes

This should solve the issue and get your VPN connection working again.

Markco

thanks very much. 😉
work fine now 😉

Yacostate

Naive question, but does it matter where in the configuration file I insert the code to fix the error?

I've placed it near the top, but still getting the same error message:

client
nobind
dev tun
remote-cert-tls server
comp-lzo yes
allow-compression yes
—data-ciphers-fallback BF-CBC

openvpn_inc

Hello,

I just want to provide a bit of background on this. In the past compression was an option that could be enabled, with the idea that easily-compressable data could be minimized and thus take less time to transfer. But the Voracle vulnerability that was discovered when compression and encryption are combined proved that there is no sensible way to have compression and be absolutely sure that no data could be gleaned from the compressed and encrypted data. The trick is in the length of compressed and encrypted data that can give a clue about what's in the original data. If you're interested to learn more, read up on Voracle vulnerability.

In short though, this meant OpenVPN had to phase out compression.

Modern clients are capable of using DCO. DCO, or Data Channel Offload, is a new addition to OpenVPN where transportation of data can be handled in the kernel, which is faster. Obviously it makes no sense to implement a feature like compression in DCO when it is known to be flawed. So DCO does not have compression support and will not get it either (because that would be insecure and silly to do).

The situation described in the original post by Markco is the case where the client side wants to use DCO. And the server side is telling the client to do compression. In such a case, the client side will abort, because that's not possible, because the client side uses DCO and it does not know how to do compression and never will.

The suggestion that Fadim provided was to use the mentioned allow-compression option to turn compression on, on the client side. Doing so forces DCO off, because DCO cannot do compression. So the client has now become a little 'dumber' and falls back to non-DCO behavior. So it doesn't use the kernel module to speed up data transfer, but it just goes back to using good old OpenVPN data transfer without that new stuff. And that still does support compression, even though it is not encouraged for security reasons of course.

However the suggestion specifically enables compression in both directions. It may be wiser instead to do allow-compression asym which lets the client receive compressed data from the server (since it has no control over what the server sends anyway), but at least it doesn't SEND compressed data by itself. So at least the client side is being 'safe'.

The better solution would be to have the server side reconfigured to adjust compression options, so it doesn't use compression and doesn't tell clients to use compression either. This addresses the Voracle vulnerability issue when compression is enabled, which is good for security. And it allows DCO to be used, which is good for performance.

Hopefully this information will be useful to someone in the future.

Kind regards,
Johan