Any chance to get encryption over l2tp offloading?

[micw]

Hello,

I created a simple docker based test setup (https://github.com/freifunkstuff/fastd-test). When running on a multi-core VPS, I can acieve up to 25mByte/s with encryption and 30 mByte/ss without encryption which both saturates one CPU core per client/server.

When I switch to l2to offloading, I the the maximum from my VPS (100 mByte/s) without any relevant CPU usage which is phantastic.

Do you see any chance to implement encryption over l2tp offloading? Or if not on l2tp offloading, is there maybe another kernel module (like wireguard or ipsec) that allows kernel offloading + encryption together?

IMO this is an extremely important feature to communities like "freifunk" which build L2 networks on top of fastd. There are other workarounds out there that uses wireguard + a L2 layer on top which adds a lot of complexity.

[neocturne]

The reason why L2TP is fast is that the whole data path is entirely handled in the kernel - fastd doesn't see any of the traffic, so there is no way for fastd to do any encryption. The common solution for encrypted L2TP is wrapping the whole connection in IPsec, which is complex to configure and requires additional userspace software (which is not aligned with fastd's main design goal to be usable on very small embedded Linux devices).

The best idea I have to have to get an encrypted connection with a fast in-kernel data path would be to make fastd an alternative userspace for the wireguard kernel module. This unfortunately doesn't solve the problem of wireguard's missing L2 support...

[micw]

So, what we need is a kernel offloading module at L2 level with encryption support? E.g. something like l2tp that gets a symmetric key as a parameter (and maybe some re-keying mechanism from time to time)?

[neocturne]

I don't intend to support any out-of-tree module, and I don't think getting another separate solution after Wireguard into the mainline kernel is feasible. That leaves us with a few options:

• Extend Wireguard with proper L2 support
• Combine Wireguard with VXLAN/GRETAP/..., possibly with integrated handling in fastd (performance penalty?)
• Add an IPv6 encapsulation feature to batman-adv (I have no idea if this makes sense)
• Accept that there is no nice solution with batman-adv, and hope for better support of L3 mesh routing protocols in Gluon
• Other ideas?

[micw]

I think, "Extend Wireguard with proper L2 support" would be the best solution here. Unfortunately, wireguard started as a L3 only solution from the beginning. It might be hard to convince the devs there to support L2.
A good starting point might be to ask them to remove the "more useful than IPsec" statement from their homepage unless they implement L2 ^^

[neocturne]

A good starting point might be to ask them to remove the "more useful than IPsec" statement from their homepage unless they implement L2 ^^

I don't think that's quite accurate - IPsec also only handles IP after all, L2 would be provided by some other encapsulation protocol inside the IPsec-protected packets, like L2TP. So in that regard, Wireguard isn't less useful than IPsec.