Hacker News Reader

Comment by tssva | Hacker News Reader

When Wireguard was 1st rolled out the smaller code base vs OpenVPN was touted as a feature. Now that 3rd party systems are available to bring feature parity with OpenVPN, it would be interesting to see a comparison of the size of the code base inclusive of these 3rd party systems. Not interesting enough for me to put forth the effort to do it but still interesting.

View on HN

First, even with third-party code, WireGuard is going to be significantly smaller than OpenVPN (and significantly easier to audit).

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.

"First, even with third-party code, WireGuard is going to be significantly smaller than OpenVPN (and significantly easier to audit)."

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.

Yes, there is plenty of evidence for this; see for instance the WireGuard paper. Numerous code size comparisons have been done here.

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.

Plenty of code size comparisons with Wireguard and 3rd party apps providing feature parity with OpenVPN? Can you provide some links?

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.

You were asking whether Wireguard's design goals and criteria still hold up and the answer to that is that they do.

I never asked that! I said it would be interesting to see how the line count of Wireguard and the 3rd party software needed to bring it in feature parity with OpenVPN compared with OpenVPN since the line count of Wireguard by itself is touted as an advantage.

It's not 'touted as an advantage' based on line count alone and the 'feature parity' thing doesn't apply as explained in the comments above.

The hand waving and moving goalposts would be less glaring if you, you know, mention a single use case where WG is supposedly the inferior solution?

What hand waving and moving of goalposts it that? All I stated was that it would be interesting to see a comparison of line count of Wireguard and the 3rd party tools needed to bring it into feature parity with OpenVPN to the line count of OpenVPN. My above comment just asked for references to studies doing just that which the comment I was responding to claimed to exist.

Large organizations sometimes use Strongswan bc it has stuff like CAs integrated. (Ok, it's using IPsec, but that's still not OpenVPN)

OpenVPN doesn't have awesome credential management baked in and the core networking code is an order of magnitude more complex, which is why the performance sucks compared to wireguard.

While not totally awesome, OpenVPN is miles beyond Wireguard when it comes to credential management. There are several auth plugins, you can use "the usual stuff" like PAM, and through that LDAP/Kerberos, ActiveDirectory, RADIUS, etc.. For higher security demands, client certificates are also possible and standardized X.509, PKCS#11/15 like CaC, Yubikeys and usual employee ID cards work. Also, OpenVPN supports at least some form of IP assignment and DNS/Route management.

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.

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

The problem with the building block approach is that it usually compromises any supposed security advantages Wireguard may have. You get a supersecure bank safe where the key is handed to you in the baker's shop opposite if you ask nicely.

I don’t believe that’s the case.

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.

The complexity doesn’t even help it work well. For example:

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

The feature parity I'm waiting for is L2 VPNs. Wireguard is strictly L3-only, and so far all I've seen are some custom hacks to tunnel L2 ethernet frames over wg.

Wireguard is L3 encryption. It's great because it's simple. Linus called it poetry. If you are bridging L2 over the Internet, then one way or another you're stuffing Ethernet frames into IP packets. Linux has built in L2 tunneling, sans encryption. I wouldn't call it a custom hack to open an L2 tunnel over wireguard. It's a one liner on each end. A configuration utility like wg-quick could be made to set it up for you. I wouldn't want wireguard to become OpenVPN.

> I wouldn't call it a custom hack to open an L2 tunnel over wireguard

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.

Regardless of the technology, there is no way to put an 1518 byte Ethernet frame in a 1500 byte IP packet. You're going to have to fragment or live with reduced MTU inside the tunnel.

What do you need L2 for these days?

https://github.com/m13253/VxWireguard-Generator

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.

Reply on news.ycombinator.com