Re: test of lzo option in OpenVPN

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 2795 bytes --]

Hello Adolf,

Thank you for checking this one out.

> On 4 Sep 2023, at 21:15, Adolf Belka <adolf.belka(a)ipfire.org> wrote:
> 
> Hi All,
> 
> On 04/09/2023 21:51, Adolf Belka wrote:
>> Hi All,
>> 
>> As discussed in the conf call I did a test of the LZO option and the result was not what I had hoped for, at least with Network Manager - openvpn plugin.
>> 
>> Using my vm testbed, I created a client with LZO option enabled.
>> 
>> I made an opnvpn connection which was successful and worked.
>> 
>> Then I disabled LZO on the server but left the client as it was.
>> 
>> Remade the connection. The connection showed as CONNECTED in the openvpn WUI page but in my Arch Linux log for the network manager I got a periodic message of
>> 
>> nm-openvpn[1266]: Bad LZO decompression header byte: 42
>> 
>> Additionally trying to use the browser through the tunnel failed with the web sites timing out.
>> 
>> So at least with Network Manager Openvpn plugin turning LZO off on the server ,when the client has it specified, does not work the way we discussed.
>> 
>> I will do a further test with openvpn directly on the command line but if one openvpn client doesn't accept LZO being turned off on the server if it is enabled in the client this means we can't remove the LZO option and default it to disabled on the WUI page.
>> 
> The same problem occurs when using openvpn as a client from the command line. LZO on the client and server works fine or both disabled works fine but lzo on client but turned off on server gives the same error message as found with network manager - openvpn plugin and although the Status shows as CONNECTED no traffic is successfully passed due to the compression mismatch.
> 
> Conclusion: we can't remove the LZO option from the WUI page and have it default to off for everyone.

This is sad, but I think we already anticipated this.

I am now wondering what will happen when this option gets removed upstream (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-lzoStatus:Pendingremoval). It hasn’t been decided, yet, but it is at least deprecated and already does not actually enable any compression.

That being said, we should remove the checkbox anyway then, because the page says:

  Beginning with 2.5, these options will no longer enable compression, just enable the compression framing to be able to receive compressed packets.

So it is misleading to users right now because there is no compression whatsoever, it just enables an extra header which wastes space.

It should not be possible to enable this on new installations.

What do we do with this chaos now?

-Michael

> 
> Regards,
> 
> Adolf.
> 
>> Regards,
>> 
>> Adolf.
>> 
> 
> -- 
> Sent from my laptop