2.4 "compress" backward compatibility with 2.3 "comp-lzo no" (possible bug?)

[Melvin_Dalton]

According to https://community.openvpn.net/openvpn/w ... n24ManPage, setting "compress lzo" is the same as setting the option "comp-lzo yes":

"For backwards compatibility with OpenVPN versions before v2.4, use "lzo" (which is identical to the older option "--comp-lzo yes")."



So, does that also mean that setting the option "compress" with no parameters is the same as setting the older option "comp-lzo no"?

I am having an issue with my VPN provider. I am on XP / OpenVPN 2.3.18, and the VPN recently updated their servers to 2.4.x. It connects, but then no data transfers, and I get "Bad LZO decompression header byte" entries in the log file before it reconnects due to an inactivity timeout. This keeps repeating after every minute due to inactivity timeout (no data can be sent or received through the tunnel due to these bad headers).

There is also an entry in the log file, "Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: compress (2.3.18)"

The VPN says they only have "compress" as a push option with no parameter; LZO or LZ4 isn't specified. Logs seem to confirm that.

https://community.openvpn.net/openvpn/w ... n24ManPage says about "compress" (in the above screen capture): "If the algorithm parameter is empty, compression will be turned off, but the packet framing for compression will still be enabled, allowing a different setting to be pushed later."

For "comp-lzo no", it says "This will turn off compression by default, but allow a future directive push from the server to dynamically change the on/off/adaptive setting." Is this happening through the same "packet framing" tech that 2.4 is using, or is 2.4 using something new / different?

If it's different, then I guess that explains the incompatibility. But if it's supposed to be the same (i.e., backwards compatible), then this might be a bug?

It does seems a bit silly to have backwards compatibility for "compress lzo" <---> "comp-lzo yes", but not for "compress" <---> "comp-lzo no", if that is indeed the case.

OpenVPN Config (from VPN):

View Originalclient

remote xxx.xxx.xxx.xxx 8008 tcp
cipher AES-128-CBC
auth SHA512
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
client
verify-x509-name california name
dev tun
resolv-retry 20
route-delay 2
comp-lzo no
remote-cert-tls server
nobind
auth-user-pass auth.txt
key-direction 1
<ca>
-----BEGIN CERTIFICATE-----
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************
-----END CERTIFICATE-----
</ca>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
********************************
-----END OpenVPN Static key V1-----
</tls-auth>

Log file:
Wed Oct 11 02:33:27 2017 OpenVPN 2.3.18 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Sep 26 2017
Wed Oct 11 02:33:27 2017 Windows version 5.1 (Windows XP) 32bit
Wed Oct 11 02:33:27 2017 library versions: OpenSSL 1.0.2l 25 May 2017, LZO 2.10
Enter Management Password:
Wed Oct 11 02:33:27 2017 Control Channel Authentication: tls-auth using INLINE static key file
Wed Oct 11 02:33:27 2017 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.236:8008 [nonblock]
Wed Oct 11 02:33:28 2017 TCP connection established with [AF_INET]xxx.xxx.xxx.236:8008
Wed Oct 11 02:33:28 2017 TCPv4_CLIENT link local: [undef]
Wed Oct 11 02:33:28 2017 TCPv4_CLIENT link remote: [AF_INET]xxx.xxx.xxx.236:8008
Wed Oct 11 02:33:29 2017 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Oct 11 02:33:30 2017 [california] Peer Connection Initiated with [AF_INET]xxx.xxx.xxx.236:8008
Wed Oct 11 02:33:33 2017 Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: compress (2.3.18)
Wed Oct 11 02:33:33 2017 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Oct 11 02:33:33 2017 open_tun, tt->ipv6=0
Wed Oct 11 02:33:33 2017 TAP-WIN32 device [TAP-Windows Adapter V9] opened: \\.\Global\{DB99BA9D-6BDB-4208-8369-DBDE740BD1EA}.tap
Wed Oct 11 02:33:33 2017 Set TAP-Windows TUN subnet mode network/local/netmask = xxx.xxx.xxx.128/xxx.xxx.xxx.130/255.255.255.240 [SUCCEEDED]
Wed Oct 11 02:33:33 2017 Notified TAP-Windows driver to set a DHCP IP/netmask of xxx.xxx.xxx.130/255.255.255.240 on interface {DB99BA9D-6BDB-4208-8369-DBDE740BD1EA} [DHCP-serv: xxx.xxx.xxx.142, lease-time: 31536000]
Wed Oct 11 02:33:33 2017 Successful ARP Flush on interface [327684] {DB99BA9D-6BDB-4208-8369-DBDE740BD1EA}
Wed Oct 11 02:33:36 2017 Initialization Sequence Completed
Wed Oct 11 02:33:53 2017 Bad LZO decompression header byte: 42
Wed Oct 11 02:33:54 2017 Bad LZO decompression header byte: 69
Wed Oct 11 02:34:02 2017 Bad LZO decompression header byte: 69
Wed Oct 11 02:34:09 2017 Bad LZO decompression header byte: 69
Wed Oct 11 02:34:29 2017 Bad LZO decompression header byte: 42
Wed Oct 11 02:34:33 2017 [california] Inactivity timeout (--ping-restart), restarting
Wed Oct 11 02:34:33 2017 SIGUSR1[soft,ping-restart] received, process restarting
Wed Oct 11 02:34:38 2017 Attempting to establish TCP connection with [AF_INET]xxx.xxx.xxx.236:8008 [nonblock]
Wed Oct 11 02:34:39 2017 SIGTERM[hard,init_instance] received, process exiting

[TinCanTech]

The current situation is this.

Openvpn 2.3.x is essentially only for people who use WinXP, everybody else should use 2.4.x

Openvpn keep the 2.3 branch current because they know that there are still a lot of people using WinXP
and they want to provide them with some ongoing support. But this will end eventually.

The problem you have is that your VPN service provider has configured their server incorrectly.

About the only things you can do are

• contact the provider and explain that to them
• find another provider
• Upgrade your Operating System (Recommended, try Linux Mint)

[Melvin_Dalton]

Can you please explain, how the VPN provider has configured their server incorrectly?

I'm trying to communicate with them and this would be super helpful info!

[TinCanTech]

Their server is pushing --compress to clients which do not understand it.
--compress is not present in openvpn 2.3 .. and that is only the tip of the iceberg.

[Melvin_Dalton]

So they should be using "comp-lzo no" instead, right?

[TinCanTech]

I have no idea what Their end goal is .. I cannot give any further information.

[Melvin_Dalton]

Well, this doesn't address my original question:

Does "compress" on 2.4 = "comp-lzo no" on 2.3? Because then the client should still be able to read the packets without "Bad LZO decompression header byte" errors, despite the "Unrecognized option" message.

https://community.openvpn.net/openvpn/w ... n24ManPage says that "compress lzo" = "comp-lzo yes" and that it's backwards compatible with clients older than 2.4... which to me would imply that "compress" = "comp-lzo no"... why have packet compatibility for "compress lzo" / "comp-lzo yes", but not "compress" / "comp-lzo no" ?

[dazo]

The crux of the issue here is that the server pushes an option which is not available in OpenVPN v2.3. So the v2.3 complains about it and the decryption is failing as the it might be the data being pushed over the tunnel is using LZ4. If you change your config to use --verb 4, you can see the exact parameters being pushed from the server to you. You can also try to use --comp-lzo yes, and see if that makes your client more happy - but I'm not fully convinced that's the issue.

But even better ... upgrade your OpenVPN client to the latest v2.4. Then you get both --compress and LZ4 support, plus even better crypto.

[Melvin_Dalton]

Can't upgrade to 2.4 on XP, or on other devices that use 2.3.

[Melvin_Dalton]

You're right... I did a "verb 4" and see that it is in fact using LZ4-v2. They told me they don't use that, but they are incorrect.

Is there a reason LZ4-v2 can't be added to 2.3? Can XP not use that? I do realize that there are significant issues for XP that would take too much time and effort to work around to support for 2.4, but is the new "Compress" option and LZ4-v2 really one of these issues? I thought LZ4-v2 had been around for quite some time now.

[dazo]

The change-set required is quite intrusive. With v2.3, we do primarily only bug and security fixes, no feature changes. Occasionally we add some minor features, but only the non-intrusive ones if really needed. And in not too far future, we will ramp up the development of v2.5, and then v2.4 will also not see too massive changes either. This is all to ensure our releases are as stable and solid as possible.

LZ4 itself has been available for quite some time. But the OpenVPN implementation adding LZ4 support is far newer.

[Melvin_Dalton]

Isn't there a way for the VPN to configure their servers, so that they only use "compress lz4-v2" with clients that support it (i.e., clients that are version 2.4 or greater)?

Or do server configs only work globally (i.e., "push" settings can only apply to all clients).

Thanks for the helpful information by the way. I have an older but robust XP machine that uses VPN and it's got some heavy customizations on it... I can replace it but it will be a huge task. Don't want to have to do it when it still works for what it's for! I know it will have to be replaced at some point, but like a lot of people, I get stuck "in the moment" and don't want to have to fix something that's still currently working.

Think about this... mp3 is basically late 80's / early 90's tech, but it still persists, despite many superior and better formats available today. People like backwards compatibility. (I can play it on everything!)

[Melvin_Dalton]

I've read some other posts from people who confirm that the Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:5: compress (2.3.18) message won't affect 2.3.x clients as long as either no compression or LZO compression is used. LZ4 of course won't work. It would be nice of course if someone could figure out a way to fork or add just LZ4 support to 2.3 in a modded compile to get some extended support out of it. (But from what I've read compiling the Windows version of OpenVPN is apparently very difficult.)

However, I asked some other people and they say there isn't currently a way to configure an OpenVPN server to say, "If client =>2.4 then use LZ4, if client is <2.4 then don't use any compression or use LZO."

Is that correct?

[TinCanTech]

Openvpn can support mixed compression and filter by client with ease.

[Melvin_Dalton]

Can you please post an example for server.conf? It would be very helpful.

Again, I need an example of "If client =>2.4 then use LZ4, if client is <2.4 then don't use any compression or use LZO."