From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: test of lzo option in OpenVPN Date: Tue, 05 Sep 2023 21:17:44 +0200 Message-ID: <1a285ae9-9b13-42cc-a422-4e971314a568@ipfire.org> In-Reply-To: <611FE5F4-9CF4-4A09-BFAC-8847323A5C83@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0847678988649782870==" List-Id: --===============0847678988649782870== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 05/09/2023 18:30, Michael Tremer wrote: > Hello Adolf, >=20 > Thank you for checking this one out. >=20 >> On 4 Sep 2023, at 21:15, Adolf Belka 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 resu= lt was not what I had hoped for, at least with Network Manager - openvpn plug= in. >>> >>> 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 me= ssage 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 se= rver ,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 i= s 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 li= ne. LZO on the client and server works fine or both disabled works fine but l= zo on client but turned off on server gives the same error message as found w= ith network manager - openvpn plugin and although the Status shows as CONNECT= ED 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 d= efault to off for everyone. >=20 > This is sad, but I think we already anticipated this. >=20 > I am now wondering what will happen when this option gets removed upstream = (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--comp-l= zoStatus:Pendingremoval). It hasn=E2=80=99t been decided, yet, but it is at l= east deprecated and already does not actually enable any compression. >=20 > That being said, we should remove the checkbox anyway then, because the pag= e says: >=20 > Beginning with 2.5, these options will no longer enable compression, jus= t enable the compression framing to be able to receive compressed packets. >=20 > So it is misleading to users right now because there is no compression what= soever, it just enables an extra header which wastes space. >=20 > It should not be possible to enable this on new installations. I see what you are suggesting. We remove the checkbox in the iso and=20 image files. What we could also do is that in the next update we check if the server=20 has LZO enabled and if not then the checkbox is removed on systems not=20 using it. That then leaves the people with the LZO checkbox enabled. I would suggest that I create a patch that places a warning message in=20 red on the main OpenVPN WUI page that warns that the LZO option is not=20 compressing since version 2.5.0 and that the option has been deprecated=20 and will be removed by OpenVPN at some time in the future and requesting=20 IPFire users to update their clients to remove the LZO option. I should also test out what happens if the LZO option is enabled on the=20 server but removed on the client. Does that also break the connection.=20 The answer will probably be yes which will mean that IPFire admins will=20 need to change all clients and the server at the same time. Regards, Adolf. >=20 > What do we do with this chaos now? >=20 > -Michael >=20 >> >> Regards, >> >> Adolf. >> >>> Regards, >>> >>> Adolf. >>> >> >> --=20 >> Sent from my laptop >=20 >=20 --=20 Sent from my laptop --===============0847678988649782870==--