Wireguard has none of that, not even the notion of a user. There are just keys in a special (unsupported by anything else) format that are assigned an IP address statically in a file. Oh, and the frigging software writes into that config file if you change anything.
Wireguard is a nightmare for any attempt at sane system administration.
It’s quite simple really: WireGuard is a building block. TFA mentions several systems built on top of WireGuard, that enables sophisticated handling of users/roles, authentication, ACLs, etc.
However, the system on top of WireGuard cannot just spit out a key to the user and call it a day.
The key (sorry…) is to make the system a) verify the identity of the users via an IdP (e.g. Okta or something similar) and then b) distribute short-lived keys, that can be revoked.
If one reads how Tailscale handles user authentication and key rotation, one will notice that they have a solid system in place for handling the keys and the product is much more sophisticated than OpenVPN.
I haven’t studied the approach of their competitors (e.g. Firezone) so I can’t comment on that.
References/suggested reading: https://tailscale.com/kb/1028/key-expiry/ ⦁ https://tailscale.com/blog/tailscale-key-management/ ⦁ https://tailscale.com/customers/gini/ ⦁ https://tailscale.com/kb/1009/protect-ssh-servers/
https://web.archive.org/web/20210919013400/https://community...
OpenVPN is simply bad at networking irrespective of any security considerations. (Wireguard, AFAICT, does the right thing with regard to MTU and is much simpler as a result. OpenVPN seems to go out of its way to be wrong.)
There's too many headers that are too big. If you do a simple L2 tunnel, you have three options: jumbo frames, packet fragmentation, or custom hacks. None are great.
> Linux has built in L2 tunneling, sans encryption
IIRC, because the extra header for the encryption layer pushes the MTU over 1500.
I'm using that in production with Babel (managing dynamic routes) with great success. Tinc had been solid for us for years, but once I actually payed attention to the performance hit, it was worth a bit of hassle to make it work over wireguard.
But more importantly, you can't just count lines of code as if they're all equivalent. There's a trusted core of code that is more important than the rest of the code, and WireGuard's trusted code is microscopic compared to OpenVPN. That's the right word in this case: "microscopic". It's some of the easiest code in the whole kernel to read, even given the cryptography.
Do you have some evidence for that or is it just speculation?
"But more importantly, you can't just count lines of code as if they're all equivalent."
You're right but the Wireguard white paper conclusion claims an advantage for Wireguard based solely upon the lines of code needed to implement.
OpenVPN, Wireguard and IPsec all have their advantages and disadvantages. I have and will use all 3 where appropriate based upon them.
Further, that is not what the WireGuard paper concludes. For instance: the paper makes a note of the fact that WireGuard is designed to be implemented without dynamic memory allocation, which is not a function of lines of code (in fact, it probably adds lines of code).
You do you, but as a practitioner in this space, I'd say using OpenVPN or IPSEC in 2022 without some powerful compatibility, regulatory, or network complexity concern to support it is malpractice. You might disagree, but I think you'd be in the minority of security engineers on the point. Feel free to ask around! The codebases for OpenVPN and the IPSECs are reviled.
The Wireguard paper makes notes of many things including the lines of code needed to implement.
"I'd say using OpenVPN or IPSEC in 2022 without some powerful compatibility, regulatory, or network complexity concern to support it is malpractice."
Life is complicated and those type of concerns are almost always in play which means OpenVPN and IPsec are also always in play. Wireguard is great where it is a fit but there are characteristics of Wireguard which also make it the more complicated and fragile solution in some circumstances.