@benjojo Sounds like a sane approach. The KEX/Auth part in OpenVPN is much more complex than the single encryption algorithm in Wireguard. That approach will solve some problems we currently have, as the user space OpenVPN server will stop forwarding traffic if it get stuck. Our auth plugin blocks sometimes and then impact OpenVPN forwarding for all logged in users.

@benjojo what is more, to use more then a single core for OpenVPN, one must setup load balancing across multiple OpenVPN Daemons on the same host, as OpenVPN ist single threaded.

@benjojo Long, long overdue. I guess this makes sense.

@benjojo Since it uses TLS (among other things) for auth, it makes a lot of sense for that to remain in userspace (like how the TLS handshaking for NFS and NVMe-oF is in user-space as well). All-kernel all-static configuration is what makes WG really unsuitable for "user" VPNs...

@benjojo but wg only needs static key pairs, whereas openvpn has a more complex authentication system, where some methods are interactive (client-side) or require access to an external database (server-side)

@benjojo very curious to see how they ended up handling the P2MP peer selection. I talked to them at netdevconf in Portugal and recommended they look at how GRE/NHRP and app_solicit works, but no idea if that's viable for them.

There's also lwt on routes, but then the routing system has to deal with it... (app_solicit would allow for a full separation, it's like ARP in that installing a route with a nexthop triggers MAC resolution automatically)