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: Wed, 06 Sep 2023 14:54:34 +0100 Message-ID: <40CBBFE4-CD77-44DD-966D-D330B49AC4AE@ipfire.org> In-Reply-To: <1a285ae9-9b13-42cc-a422-4e971314a568@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1594649324464966426==" List-Id: --===============1594649324464966426== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 5 Sep 2023, at 20:17, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 05/09/2023 18:30, Michael Tremer wrote: >> 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 res= ult was not what I had hoped for, at least with Network Manager - openvpn plu= gin. >>>>=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= WUI page but in my Arch Linux log for the network manager I got a periodic m= essage of >>>>=20 >>>> nm-openvpn[1266]: Bad LZO decompression header byte: 42 >>>>=20 >>>> Additionally trying to use the browser through the tunnel failed with th= e web sites timing out. >>>>=20 >>>> So at least with Network Manager Openvpn plugin turning LZO off on the s= erver ,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 i= f 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 defaul= t it to disabled on the WUI page. >>>>=20 >>> The same problem occurs when using openvpn as a client from the command l= ine. 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 CONNEC= TED 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 = 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=E2=80=99t 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 pa= ge says: >> Beginning with 2.5, these options will no longer enable compression, jus= t enable the compression framing to be able to receive compressed packets. >> So it is misleading to users right now because there is no compression wha= tsoever, it just enables an extra header which wastes space. >> 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 image = files. >=20 > What we could also do is that in the next update we check if the server has= LZO enabled and if not then the checkbox is removed on systems not using it. That was my first thought as well, but what do we do with those people who di= sable it not knowing what they are doing and then needing to re-enable 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 red = on the main OpenVPN WUI page that warns that the LZO option is not compressin= g since version 2.5.0 and that the option has been deprecated and will be rem= oved by OpenVPN at some time in the future and requesting IPFire users to upd= ate their clients to remove the LZO option. I think a solution could be that we add some kind of =E2=80=9Ccompatibility= =E2=80=9D counter. Basically we set this to like =E2=80=9C1=E2=80=9D, or the = current date: COMPAT=3D20230906 And then we check that value when we decide whether to show the LZO box. Olde= r systems don=E2=80=99t have the value set, newer systems will start this val= ue as shown above. That way we keep things as they are for users who are coming from an older ve= rsion, and we remove all the nonsense for the new users. That might work well= for the latter group. However, it might be confusing because some installations have other features= available than others. And for us as developers, this means that we actually= never ever remove LZO. We will have to carry this shit around for basically = forever. > I should also test out what happens if the LZO option is enabled on the ser= ver but removed on the client. Does that also break the connection. The answe= r will probably be yes which will mean that IPFire admins will need to change= all clients and the server at the same time. I believe this will also break the connection. -Michael >=20 > Regards, >=20 > Adolf. >> What do we do with this chaos now? >> -Michael >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>=20 >>> --=20 >>> Sent from my laptop >=20 > --=20 > Sent from my laptop --===============1594649324464966426==--