This is a very interesting project as all our today's processors, even the Raspberryian ones, are multicores.

I assume the author does not want to rewrite OpenVPN from the scratch. Because "Multithreading", "networking" and "cryptography" immediately raises the head bells when it comes to C. People write this in Rust nowadays, isn't it? ;-)

I don't know if you are aware of it, but "Fri" means "Free" in Swedish so I thought you picked a rather interesting name for your project. Looks cool!

But that doesn't help if the server isn't multithreaded, no?

Also these days I switched to IPsec. I just get way better performance than with OpenVPN (I am talking about 600 Mbit/s vs 350Mbit/s). But it is quite a beast and you need to have some basic cryptographic knowledge for IPsec.

EDIT: Seems like my first question is only relevant if we are talking about powerful CPUs on both sides. If multicore on client <= single core on server, then this client makes sense.

This is pretty neat. I looked at the current limitations, though, and a lot of them are things that damage performance, or greatly limit compatibility (TCP-only, no client certs, lzo compression required, only one choice of algorithm). I expect many of these will get fixed over time.

Since sandy bridge, I thought all CPUs had AES-NI baked into the silicon. Hardware based crypto is much faster than software based so why is core count a concern?

Now switch to WireGuard for even better performance.