OpenVPN Server with "comp-lzo adaptive"

[Tom VanHook]

RT-AC87U running 384.13_10

Bottom line up front:

a. Compression is hackable, and probably a bad idea in the first place.
b. LZ4 is better than LZO.
c. Adaptive LZO no longer exists on the client side.

Issue involves OpenVPN server. I'm NOT an encryption expert, so feel free to correct me if the details are off. The gist is important.

I used what (I think...) are the default OpenVPN server settings, which use "Adaptive LZO" compression.

The exported configuration file worked in Windows, but not on my Mac. Well...it worked on a Mac (using Tunnelblick), but gave an annoying warning that "'comp-lzo' was deprecated in OpenVPN 2.4 and has been or may be removed in a later version".

So I dug into the issue a little bit.

At first glance, the option is still there...with new syntax. It's now "compress lzo". That's what you'll discover with a brief search.

And that's what I tried to do. I changed the line in the exported configuration file from "comp-lzo adaptive" to "compress lzo".

BUT THEY WERE, ALL OF THEM, DECEIVED, FOR ANOTHER OPTION WAS MADE...

https://forums.openvpn.net/viewtopic.php?t=23845

There's no way, with the new syntax, to select adaptive LZO compression. Looks like you either have compression, or you don't.

So now it's possible to select a server option...and it might even be the default...of "lzo adaptive"...that a client can't handle.

Ugh.

So I changed the compression to regular "LZO", and edited the configuration file from "comp-lzo yes" to "compress lzo".

So that worked fine on the Mac, but not Windows. Ugh. Ugh.

Then I realized that the Windows OpenVPN client has an option, "Allow Compression (insecure)". If I selected "Full", the new configuration file worked fine on both machines.

Then I drilled into the "insecure" warning...and found...

https://www.pcmag.com/news/compression-and-vpns-make-for-leaked-secrets

Something about compression headers being a consistent string, and therefore subject to a brute force attack. Kinda like the "good morning" used to crack Enigma.

Ugh. Ugh. Ugh.

TL;DR,

1. Turn off compression. I suggest doing this by default, as the default settings led me into this rabbit hole. If you really want to use it, use LZ4. LZO if you need backwards compatibility. And don't use "LZO Adaptive" at all.
2. Change "comp-lzo" to "compress lzo" in the client configuration files, or Tunnelblick will give you an error. And that error might actually mean something someday.
3. I suggest removing "LZO Adaptive" as an option, and exporting "compress lzo" instead of "comp-lzo".
4. If you're gonna use compression, enable it in the Windows client. It's disabled by default.

 

[elorimer]

RT-AC87U running 384.13_10

Issue involves OpenVPN server. I'm NOT an encryption expert, so feel free to correct me if the details are off. The gist is important.

I had an exported configuration file that worked in Windows but not on my Mac. Well...it worked on a Mac (using Tunnelblick), but gave an annoying warning that "'comp-lzo' was deprecated in OpenVPN 2.4 and has been or may be removed in a later version".

So I dug into the issue a little bit.

At first glance, the option is still there...with new syntax. It's now "compress lzo". That's what you'll discover with a brief search.

And that's what I tried to do. I changed the line in the exported configuration file from "comp-lzo adaptive" to "compress lzo".

BUT THEY WERE, ALL OF THEM, DECEIVED, FOR ANOTHER OPTION WAS MADE...

https://forums.openvpn.net/viewtopic.php?t=23845

There's no way, with the new syntax, to select adaptive LZO compression. Looks like you either have compression, or you don't.

So now it's possible to select a server option...and it might even be the default...of "lzo adaptive"...that a client can't handle.

Ugh.

So I changed the compression to regular "LZO", and edited the configuration file from "comp-lzo yes" to "compress lzo".

It now works just fine on both machines.

TL;DR,

1. Don't use "LZO Adaptive" compression.
2. Change "comp-lzo" to "compress lzo" in the client configuration files, or Tunnelblick will give you an error. And that error might actually mean something someday.
3. I suggest removing "LZO Adaptive" as an option, and exporting "compress lzo" instead of "comp-lzo".

Short answer, we've moved on. Don't enable or use compression at all.

 

[elorimer]

I see the OP has been edited. Just to clarify again, there is a difference between compression being disabled and "none". There is no "off". Disabled means the traffic is framed without compression being possible. None means the traffic is framed so that compression could be enabled but is not enabled on the server side. Both server and client need to match: if one is enabled and the other not, or both are enabled but the type is not the same, then a connection will be made but no traffic will pass.

Presumably if the servers are set to disabled we won't have to change the configurations in place when compression is removed.