From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka <adolf.belka@ipfire.org> To: development@lists.ipfire.org Subject: Re: test of lzo option in OpenVPN Date: Sat, 09 Sep 2023 13:18:08 +0200 Message-ID: <7c5eb8c0-756c-4be2-999d-823cf8d642a5@ipfire.org> In-Reply-To: <40CBBFE4-CD77-44DD-966D-D330B49AC4AE@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0706128600789881551==" List-Id: <development.lists.ipfire.org> --===============0706128600789881551== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, On 06/09/2023 15:54, Michael Tremer wrote: > Hello, >=20 >> On 5 Sep 2023, at 20:17, Adolf Belka <adolf.belka(a)ipfire.org> 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 <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 re= sult was not what I had hoped for, at least with Network Manager - openvpn pl= ugin. >>>>> >>>>> 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 openvp= n 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 t= he 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 defau= lt 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 CONNE= CTED 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 upstrea= m (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. I found somewhere in OpenVPN, although I can't find it again now, a comment t= hat most likely compression will get removed completely in the pre-2.7 era wh= ich leads me to believe that it will probably be tested out in the rc version= s of 2.7 >>> That being said, we should remove the checkbox anyway then, because the p= age says: >>> Beginning with 2.5, these options will no longer enable compression, j= ust enable the compression framing to be able to receive compressed packets. >>> So it is misleading to users right now because there is no compression wh= atsoever, 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. >> >> What we could also do is that in the next update we check if the server ha= s LZO enabled and if not then the checkbox is removed on systems not using it. >=20 > 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 red= on the main OpenVPN WUI page that warns that the LZO option is not compressi= ng since version 2.5.0 and that the option has been deprecated and will be re= moved by OpenVPN at some time in the future and requesting IPFire users to up= date their clients to remove the LZO option. >=20 > 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: >=20 > COMPAT=3D20230906 >=20 > And then we check that value when we decide whether to show the LZO box. Ol= der systems don=E2=80=99t have the value set, newer systems will start this v= alue as shown above. So that would be file that is saved in the /var/ipfire/ovpn/ directory and wo= uld also need to be backed up. >=20 > 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 we= ll for the latter group. I think that should work okay. >=20 > However, it might be confusing because some installations have other featur= es available than others. And for us as developers, this means that we actual= ly never ever remove LZO. We will have to carry this shit around for basicall= y forever. If I understand correctly, it would not be a difference in the cgi code but a= n 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/or = N2N. I think that could work. In terms of having to have that code there for ever a way around is that in o= penvpn-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 a= llows migration away from the --compress/--comp-lzo options to no compression= . This option sets the server to no compression mode and the server behaves i= dentical to a server without a compression option for all clients without a c= ompression in their config. However, if a client is detected that indicates t= hat compression is used (via OCC), the server will automatically add --push c= ompress stub-v2 to the client specific configuration if supported by the clie= nt and otherwise switch to comp-lzo no and add --push comp-lzo to the client = specific configuration. ******** This would allow us to remove all the code that adds comp-lzo into the client= configurations and only create clients without compression but if a client e= xists with compression then it will be accommodated. This would allow users to progressively convert client configurations to remo= ve 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 th= ey 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 IP= Fire2.x's life. >=20 >> I should also test out what happens if the LZO option is enabled on the se= rver but removed on the client. Does that also break the connection. The answ= er will probably be yes which will mean that IPFire admins will need to chang= e all clients and the server at the same time. >=20 > I believe this will also break the connection. That is exactly what happened. So currently all clients with comp-lzo would n= eed to be updated at the same time but with the comp-migrate server option fr= om 2.6 onwards the users could have a mixture of clients with and without the= comp-lzo option. Regards, Adolf. >=20 > -Michael >=20 >> >> 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 >=20 >=20 --===============0706128600789881551==--