From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Correct installation for kernel modules Date: Fri, 20 Oct 2023 09:51:47 +0100 Message-ID: <1006781C-DD89-4ACB-B625-81AD999875CA@ipfire.org> In-Reply-To: <72d1e95c6edbb1d24df7cd585decdd971aac20cf.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3572995070314093283==" List-Id: --===============3572995070314093283== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Erik, Hmm, this is disappointing. KTLS would be a lot more universal and it is alre= ady part of the mainline kernel. I had a closer look at the repository here: https://github.com/OpenVPN/ovpn-dco It is quite noticeable that development has somewhat stalled for a while. The= re is a rather long list of issues that seem to suggest that this is not read= y for production and therefore way too hot for us in terms of potential secur= ity implications. And after all, I think if someone needs to have fast VPNs, OpenVPN is the wro= ng choice. Going away from the =E2=80=9Ceverything is in user space=E2=80=9D = paradigm does not suggest that it is the VPN technology of choice. Best, -Michael > On 20 Oct 2023, at 08:37, ummeegge wrote: >=20 > Hello Michael, >=20 > Am Mittwoch, dem 18.10.2023 um 19:42 +0100 schrieb Michael Tremer: >> Hello Erik, >>=20 >> This is interesting, because OpenVPN probably needs some >> acceleration. >>=20 >> Throughput has always been poor because of the badly implemented >> fragmentation code, that is as far as I know also deprecated and >> therefore won=E2=80=99t be improved, but we all depend on it right now. >>=20 >> However, we have only made very bad experiences with out of tree >> kernel modules. Especially since we now only have two years on the >> LTS kernels, we need to be able to rely on those maintainers to keep >> up. I don=E2=80=99t want to say anything bad about them at all, but in the >> past, even projects that have been moving well suddenly stalled and >> became a large headache for us. >>=20 >> And there might be an alternative that should be an option for >> OpenVPN (at least theoretically): KTLS. > It seems that this is not possible for OpenVPN as explained in the > freebsd mailinglist --> > https://lists.freebsd.org/pipermail/freebsd-current/2021-January/078570.html > OpenVPN uses the OpenSSL socket I/O not directly but as a data > transformation library and manage the I/O separately. >=20 >>=20 >> I did a quick Google search and could not find anything. But do you >> know how this module relates to KTLS? Can KTLS not be used in this >> case? > It seems that this is only possible for e.g. Apache, Nginx, wget, curl > and others which uses the socket directly via SSL_set_fd(), > SSL_connect(), ... and if correct compiled for Nginx e.g.=20 > =E2=80=93with-openssl-opt=3Denable-ktls > and configured in ssl_conf_command directive with the Options KTLS > parameter in the server{} context it should work transparently but for > OpenVPN it seems to be not possible to participate from KTLS. >=20 >>=20 >> -Michael >=20 > Best, >=20 > Erik >>=20 >>> On 18 Oct 2023, at 10:50, ummeegge wrote: >>>=20 >>> Hi all, >>> wanted to open a testing scenario for the OpenVPN data channel >>> offload >>> (DCO) --> >>> https://github.com/OpenVPN/openvpn/blob/master/README.dco.md >>> kernel module. So far i have been used this LFS --> >>> https://git.ipfire.org/?p=3Dpeople/ummeegge/ipfire-2.x.git;a=3Dblob;f=3Dl= fs/ovpn-dco;h=3D8b056518fa7a638dddb39955248ac5b626b9b4cd;hb=3D5f85ecb7b26628f= ccbed65c08b54e35c7f249ee5 >>> but i wanted to ask for a proper or correct way, in special the >>> installation paths of such modules but in general if i can handle >>> it in >>> such way. >>>=20 >>> Best, >>>=20 >>> Erik --===============3572995070314093283==--