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, 12 Sep 2023 14:47:23 +0100 Message-ID: In-Reply-To: <7c5eb8c0-756c-4be2-999d-823cf8d642a5@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3267138426180856185==" List-Id: --===============3267138426180856185== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 9 Sep 2023, at 12:18, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 06/09/2023 15:54, Michael Tremer wrote: >> 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 r= esult was not what I had hoped for, at least with Network Manager - openvpn p= lugin. >>>>>>=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 openv= pn WUI page but in my Arch Linux log for the network manager I got a periodic= message 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= server ,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 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. >>>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >=20 > 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 Okay, this sounds good, but again we won=E2=80=99t have any kind of contingen= cy plan to keep any existing configurations working. >>>> 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, 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 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. >>>=20 >>> 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? >=20 > Having to deal with that is very frustrating isn't it. Yes :) >=20 >>>> 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: >> 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. >=20 > So that would be file that is saved in the /var/ipfire/ovpn/ directory and = would also need to be backed up. We can just store this in /var/ipfire/ovpn/settings as a value. >> 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. >=20 > I think that should work okay. >=20 >> 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. >=20 > 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. I think that could work. >=20 > 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. >=20 > compress migrate Ah finally someone cares about this=E2=80=A6 but I am not sure if this is any= good if we only get this as yet another stepping those. Because we would sim= ply only delay the problem, but never make it go away entirely. > If we have that in the server conf file then the following applies >=20 > ******** > 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. > ******** >=20 > 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. >=20 > This would allow users to progressively convert client configurations to re= move the comp-lzo entry. If this is already available right now, we can then make it impossible to che= ck the checkbox any more. We just have to see if this system has been install= ed in the past and then always add =E2=80=9Ccompress migrate=E2=80=9D, and it= has been installed after the change, we won=E2=80=99t include that line in t= he OpenVPN server configuration. That should work well. If it is possible to push the LZO setting, maybe we should do that instead of= hardcoding it into the client configuration, too. That way it can be dynamic= ally enabled/disabled without the clients being touched. > Then eventually the whole compression aspect is just removed in OpenVPN. >=20 > 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. >=20 > Alternatively we stay with the compat option you suggested for the rest of = IPFire2.x's life. I think we might want a little bit of both? Or simple remove compression enti= rely for all installations and add =E2=80=9Ccompress migrate=E2=80=9D. >=20 >>> 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. >=20 > 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. Should we at some point create a wiki page with all the things that are going= to break? We need to get all those things together so that eventually we can= have our users do the change once and not multiple times again. -Michael >=20 > Regards, > Adolf. >=20 >> -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 --===============3267138426180856185==--