Correct installation for kernel modules

Correct installation for kernel modules

[ummeegge]

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

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

Re: Correct installation for kernel modules

[Michael Tremer]

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

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.

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?

-Michael

> 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

Re: Correct installation for kernel modules

[ummeegge]

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

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.
Interesting haven´t heared of that before.

> 
> 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?
Will give it also a research but haven´t see a concept for KTLS as a
substitution for ovpn-dco or speed acceleration for OpenVPN in general.

Another point is the limitations of ovpn-dco by design since it needs a
subnet topology but IPFire uses net30 and to implement this for
Roadwarriors we would need to change this which is a bigger task. We
spoke about that longer time ago.
What would work out of the box are Net-to-Net connections since they
use a p2p topology and the speed boost from the diagrams looks good so
far --> https://openvpn.net/blog/openvpn-data-channel-offload/ .

Anyways, will research in terms of KTLS for OpenVPN a little more and
come then back in here again.

> 
> -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
> 

Re: Correct installation for kernel modules

[ummeegge]

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

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
> 

Re: Correct installation for kernel modules

[Michael Tremer]

[-- 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