From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: test of lzo option in OpenVPN Date: Tue, 05 Sep 2023 17:30:16 +0100 Message-ID: <611FE5F4-9CF4-4A09-BFAC-8847323A5C83@ipfire.org> In-Reply-To: <275883d1-27aa-464f-afe8-33ab20c8dc16@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8589960452766702512==" List-Id: --===============8589960452766702512== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, Thank you for checking this one out. > On 4 Sep 2023, at 21:15, Adolf Belka wrote: >=20 > Hi All, >=20 > On 04/09/2023 21:51, Adolf Belka wrote: >> Hi All, >>=20 >> As discussed in the conf call I did a test of the LZO option and the resul= t was not what I had hoped for, at least with Network Manager - openvpn plugi= n. >>=20 >> Using my vm testbed, I created a client with LZO option enabled. >>=20 >> I made an opnvpn connection which was successful and worked. >>=20 >> Then I disabled LZO on the server but left the client as it was. >>=20 >> Remade the connection. The connection showed as CONNECTED in the openvpn W= UI page but in my Arch Linux log for the network manager I got a periodic mes= sage of >>=20 >> nm-openvpn[1266]: Bad LZO decompression header byte: 42 >>=20 >> Additionally trying to use the browser through the tunnel failed with the = web sites timing out. >>=20 >> So at least with Network Manager Openvpn plugin turning LZO off on the ser= ver ,when the client has it specified, does not work the way we discussed. >>=20 >> 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. >>=20 > The same problem occurs when using openvpn as a client from the command lin= e. LZO on the client and server works fine or both disabled works fine but lz= o on client but turned off on server gives the same error message as found wi= th network manager - openvpn plugin and although the Status shows as CONNECTE= D no traffic is successfully passed due to the compression mismatch. >=20 > Conclusion: we can't remove the LZO option from the WUI page and have it de= fault 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 (h= ttps://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-lzo= Status:Pendingremoval). It hasn=E2=80=99t been decided, yet, but it is at lea= st 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 e= nable the compression framing to be able to receive compressed packets. So it is misleading to users right now because there is no compression whatso= ever, 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 >=20 > Regards, >=20 > Adolf. >=20 >> Regards, >>=20 >> Adolf. >>=20 >=20 > --=20 > Sent from my laptop --===============8589960452766702512==--