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: Sat, 09 Sep 2023 13:25:26 +0200 Message-ID: In-Reply-To: <7c5eb8c0-756c-4be2-999d-823cf8d642a5@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6930618121883659839==" List-Id: --===============6930618121883659839== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, Forgot to mention that compress migrate, that I mention in my previous reply,= is recommended to migrate from compression to no compression but has also be= en deprecated and will be removed at some point (potentially in version 2.7) = together with all compression related options. Regards, Adolf. On 09/09/2023 13:18, Adolf Belka wrote: > Hi Michael, > > On 06/09/2023 15:54, Michael Tremer wrote: >> Hello, >> >>> On 5 Sep 2023, at 20:17, Adolf Belka wrote: >>> >>> Hi Michael, >>> >>> 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: >>>>> >>>>> 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 r= esult was not what I had hoped for, at least with Network Manager - openvpn p= lugin. >>>>>> >>>>>> 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 openv= pn 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 i= t is enabled in the client this means we can't remove the LZO option and defa= ult 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 bu= t lzo on client but turned off on server gives the same error message as foun= d with network manager - openvpn plugin and although the Status shows as CONN= ECTED no traffic is successfully passed due to the compression mismatch. >>>>> >>>>> Conclusion: we can't remove the LZO option from the WUI page and have i= t 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 upstre= am (https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Option:--com= p-lzoStatus:Pendingremoval). It hasn=E2=80=99t been decided, yet, but it is a= t least deprecated and already does not actually enable any compression. > > I found somewhere in OpenVPN, although I can't find it again now, a comment= that most likely compression will get removed completely in the pre-2.7 era = which leads me to believe that it will probably be tested out in the rc versi= ons of 2.7 > >>>> That being said, we should remove the checkbox anyway then, because the = page says: >>>> =C2=A0=C2=A0 Beginning with 2.5, these options will no longer enable com= pression, just enable the compression framing to be able to receive compresse= d packets. >>>> So it is misleading to users right now because there is no compression w= hatsoever, 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 imag= e files. >>> >>> What we could also do is that in the next update we check if the server h= as LZO enabled and if not then the checkbox is removed on systems not using i= t. >> >> That was my first thought as well, but what do we do with those people who= disable it not knowing what they are doing and then needing to re-enable it? > > Having to deal with that is very frustrating isn't 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 re= d on the main OpenVPN WUI page that warns that the LZO option is not compress= ing since version 2.5.0 and that the option has been deprecated and will be r= emoved by OpenVPN at some time in the future and requesting IPFire users to u= pdate their clients to remove the LZO option. >> >> I think a solution could be that we add some kind of =E2=80=9Ccompatibilit= y=E2=80=9D counter. Basically we set this to like =E2=80=9C1=E2=80=9D, or the= current date: >> >> =C2=A0=C2=A0 COMPAT=3D20230906 >> >> And then we check that value when we decide whether to show the LZO box. O= lder systems don=E2=80=99t have the value set, newer systems will start this = value as shown above. > > So that would be file that is saved in the /var/ipfire/ovpn/ directory and = would also need to be backed up. >> >> That way we keep things as they are for users who are coming from an older= version, and we remove all the nonsense for the new users. That might work w= ell for the latter group. > > I think that should work okay. > >> >> However, it might be confusing because some installations have other featu= res available than others. And for us as developers, this means that we actua= lly never ever remove LZO. We will have to carry this shit around for basical= ly forever. > > If I understand correctly, it would not be a difference in the cgi code but= an additional file that has a value. We already have various files that have= a certain value for some people and not for others depending if you RW and/o= r N2N.=C2=A0 I think that could work. > > In terms of having to have that code there for ever a way around is that in= openvpn-2.6 they have added a new mode to the compress option. > > compress migrate > > If we have that in the server conf file then the following applies > > ******** > Using migrate as compression algorithm enables a special migration mode. It= allows migration away from the --compress/--comp-lzo options to no compressi= on. This option sets the server to no compression mode and the server behaves= identical to a server without a compression option for all clients without a= compression in their config. However, if a client is detected that indicates= that compression is used (via OCC), the server will automatically add --push= compress stub-v2 to the client specific configuration if supported by the cl= ient and otherwise switch to comp-lzo no and add --push comp-lzo to the clien= t specific configuration. > ******** > > This would allow us to remove all the code that adds comp-lzo into the clie= nt configurations and only create clients without compression but if a client= exists with compression then it will be accommodated. > > This would allow users to progressively convert client configurations to re= move the comp-lzo entry. > > Then eventually the whole compression aspect is just removed in OpenVPN. > > The only potential downside is that the --push options require a client of = 2.3 or newer but if people still have OpenVPN clients of 2.2 or earlier then = they have clients that are around 10 years old and must be very vulnerable. > > Alternatively we stay with the compat option you suggested for the rest of = IPFire2.x's life. > >> >>> I should also test out what happens if the LZO option is enabled on the s= erver but removed on the client. Does that also break the connection. The ans= wer will probably be yes which will mean that IPFire admins will need to chan= ge all clients and the server at the same time. >> >> I believe this will also break the connection. > > That is exactly what happened. So currently all clients with comp-lzo would= need to be updated at the same time but with the comp-migrate server option = from 2.6 onwards the users could have a mixture of clients with and without t= he comp-lzo option. > > Regards, > Adolf. > >> >> -Michael >> >>> >>> Regards, >>> >>> Adolf. >>>> What do we do with this chaos now? >>>> -Michael >>>>> >>>>> Regards, >>>>> >>>>> Adolf. >>>>> >>>>>> Regards, >>>>>> >>>>>> Adolf. >>>>>> >>>>> >>>>> --=20 >>>>> Sent from my laptop >>> >>> --=20 >>> Sent from my laptop >> >> --===============6930618121883659839==--