Re: Correct installation for kernel modules

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3332 bytes --]

Hello Erik,

Hmm, this is disappointing. KTLS would be a lot more universal and it is already 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. There is a rather long list of issues that seem to suggest that this is not ready for production and therefore way too hot for us in terms of potential security implications.

And after all, I think if someone needs to have fast VPNs, OpenVPN is the wrong choice. Going away from the “everything is in user space” paradigm does not suggest that it is the VPN technology of choice.

Best,
-Michael

> On 20 Oct 2023, at 08:37, ummeegge <ummeegge(a)ipfire.org> wrote:
> 
> Hello Michael,
> 
> Am Mittwoch, dem 18.10.2023 um 19:42 +0100 schrieb Michael Tremer:
>> Hello Erik,
>> 
>> This is interesting, because OpenVPN probably needs some
>> acceleration.
>> 
>> Throughput has always been poor because of the badly implemented
>> fragmentation code, that is as far as I know also deprecated and
>> therefore won’t be improved, but we all depend on it right now.
>> 
>> 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’t 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.
>> 
>> 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.
> 
>> 
>> 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. 
> –with-openssl-opt=enable-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.
> 
>> 
>> -Michael
> 
> Best,
> 
> Erik
>> 
>>> On 18 Oct 2023, at 10:50, ummeegge <ummeegge(a)ipfire.org> wrote:
>>> 
>>> 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=people/ummeegge/ipfire-2.x.git;a=blob;f=lfs/ovpn-dco;h=8b056518fa7a638dddb39955248ac5b626b9b4cd;hb=5f85ecb7b26628fccbed65c08b54e35c7f249ee5
>>> 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.
>>> 
>>> Best,
>>> 
>>> Erik