Ubuntu 20.04 LTS Adds WireGuard Support | Hacker News Reader

Ubuntu 20.04 LTS Adds WireGuard Support

phoronix.com

295 pointsBella-Xiang90 comments

Great. This will mean wonders for the short-term adoption of Wireguard, as it's now in a "stable" Linux distro. After Ubuntu 20.04 there's a big gap in new "stable/enterprise" releases.

Debian 11 - Mid 2021, probably

OpenSUSE Leap/SLES 16 - Mid 2021, probably

Ubuntu 22.04 LTS - April 2022

Red Hat 9 - probably 2024 ?

So if Ubuntu hadn't included this, we would have to wait more than a year to have it in the kernel of a "server-grade" Linux system by default. Most people don't like running more cutting edge distros or fiddling with the kernel on their servers. Defaults matter, so this will be great for Wireguard adoption.

Red Hat is known to backport features into RHEL kernels. Could Wireguard conceivably make it into RHEL 8.x?

Red Hat still ships ancient versions of PHP in their official packages.

I wouldn't bet on a backport unless you have a lot of clout (a.k.a. purchasing power) behind you.

I can understand why RHEL would still ship ancient PHP versions to keep legacy apps running, but I think WireGuard would be an easier sell considering it's so unobtrusive and has no legacy software to worry about breaking.

The problem isn't "RHEL ships ancient PHP for legacy apps".

The problem is "RHEL doesn't also ship newer PHP as an alternative and you need to instead rely on third-party repositories".

RHEL themselves vendor RHSCL -- https://developers.redhat.com/products/softwarecollections/o...

For CentOS and friends there is https://www.softwarecollections.org/en/

https://access.redhat.com/products/Red_Hat_Enterprise_Linux/... are maintained by RedHat directly.

RHEL 8.2 beta brings in some kernel changes that are (maybe coincidentally) also used by Wireguard, so I don't think it's far-fetched.

I hope that it does, in the offchance that I need to do anything running on RHEL 10-15 years from now.

Why not just continue using the dkms module?

Mostly to keep my personal sanity. Joking aside, IMO having to depend DKMS to correctly build the kernel module on kernel update every time for something that is network related isn't something I would consider rock solid for production. It is great when it works. Not so great when it doesn't.

Packaging WireGuard for Fedora, CentOS, and RHEL has been super fulfilling over the years, but DKMS is super fickle and buggy. wireguard-dkms is a package I would love to see drift off into the sunset if RH backports WireGuard into EL kernels.

Likely yes. I'm discussing that possibility with them.

That sounds incredible. What kind of kernel-version differences are we talking about here? Basically... how many conflicts and what's the diffstats :)

Go look at the kernel source RPM for RHEL 6 or 7. The amount of backporting they do to keep the kernel version string from incrementing is insane.

Actually, that's not even relevant. For the last several years, I've been developing WireGuard on top of the latest kernel from Linus, while maintaining a "compat" layer to seamlessly backport it using horrendous tricks with the C preprocessor. That's allowed me to keep the codebase clean and ready for mainline Linux, while enabling people to use it on all the old kernels. I've maintained this backport layer for every kernel since Linux 3.10, including the RHEL-7 and RHEL-8 ports. This has been quite a lot of ugly work, but ultimately worth it as its given us enormous amounts of testing in odd environments, so what's shipping now in Linux 5.6 is rather polished, as opposed to being brand new and untested. We maintain some CI for this, too, testing lots of kernels and architectures. Scroll down to the "wireguard-linux-compat" section of https://www.wireguard.com/build-status/ to see.

All this is to say that there's not really much work that needs to be done by Ubuntu or RHEL or anyone else that wants to ship WireGuard -- the backporting stuff has already been done and is fairly widely deployed by now.

Wow. Non-systems dev here, but that sounds seriously impressive.

Thanks for your work. I know I will benefit from it.

Well, it worked for ZoL.

(I mean that in a positive way. I'm a fan of both... although only theoretically about WireGuard.)

I thought it was fair to wait for 2022.04 when Wireguard is only about to be included in mainline and few years in the kernel will certainly make it feel stable for the next LTS inclusion, so I was kind of surprised they went for it now as a backport.

Perhaps the code is good enough there aren't many weird bug reports to make it feel unstable.

WireGuard by now is a several-years-old codebase that has seen quite a bit of deployment, thanks to our compat layer for older kernels.

Wireguard needs to put actual logging into the product before anyone should consider using it in production.

I have to deal with it via a vendors product and have spend about 4 weeks in the past 6 months trying to fix a flaky connection by guessing and restarting a lot. Just like anything things will go wrong. But, with wireguard you have no idea what it could even be if it's not an obvious thing that you can diagnose with ping.

Wireguard also needs a better auth mechanism. I really like the simple secure key-based auth for small-scale stuff, but it's not viable for scaling at production levels. Things like user/pass auth (even if as an additional layer of security rather than displacing existing keys), 2FA, etc. will be important to get adoption at scale. I hope wireguard creates a module interface of sorts so people can extend the protocol as needed.

Wireguard doesn't need to change at the protocol level to add those features and I think thats the point. Userspace programs can be written to fetch keys from a server based on SSO or w/e.

No, I don't think it does.

The thing about simple, key-based authentication is that it's very extensible, without changing the actual protocol.

What?

Well, what Wireguard's auth actually means is that you can use whatever authentication you want to communicate a shared secret to both ends.

Want to authenticate with, say, SSH keys? Sure- SSH into a server, run a command that generates a new Wireguard key, connect in with that key.

LDAP? Same situation. Whatever SSO you want- as long as you can stick up authentication in front of a service that's able to pull bits from /dev/urandom. Multifactor? Sure.

Wireguard does one thing well. What's missing is not features in Wireguard- it's the ecosystem around it to actually handle key management. For enterprises, Hashicorp Vault or something should probably look into supporting Wireguard; for smaller situations, some SSH-based key exchange, like the way Mosh handles things, seems reasonable.

Complex, pluggable authentication is sometimes necessary...but you want as few implementations of it as possible, and you sure don't want it in the kernel if you can help it.

The problem is lots of organisations in the financial and medical worlds need 2FA. WireGuard needs a 2FA solution - It doesn’t have to be kernel based - but it does need to protect against someone grabbing a copy of the single factor auth in WireGuard (keypair). A solution that rotates/manages/provisions/etc these keypairs is still fundamentally single factor auth of the tunnel.

Nobody is arguing that there shouldn't be IdP-based WireGuard management systems. The point is that they are out of scope for the WireGuard project itself. WireGuard has an extremely straightforward configuration interface; if Okta wanted to manage WireGuard, they'd likely have no problem doing it.

Is there any decent open source 2FA / IdP management systems at the moment that work with WireGuard?

It has just landed in one distro. If there isn't yet, there certainly will be.

You don’t need a distro for this, and WireGuard has been available and in use for several years. So in that time has anyone developed a practical 2FA solution that is compatible with it?

People have. I'm unaware of any published. It's not hard. Implementing a new IdP-integrated WireGuard authorizer is probably easier than understanding IPSEC or OpenVPN in sufficient detail to secure it.

There are some attempts like subspace: https://github.com/subspacecloud/subspace but I have not found anything stable yet.

> WireGuard needs a 2FA solution - It doesn’t have to be kernel based - but it does need to protect against someone grabbing a copy of the single factor auth in WireGuard (keypair).

By this standard, no website supports 2FA- ultimately it's just a cookie that's used to authenticate requests, even though to get that cookie you may have to go through 2FA. Nothing prevents an attacker from just grabbing the session cookies.

In fact, I doubt any VPN supports 2FA by this definition- it would mean requiring authentication on every packet. Instead, of course, what you do is do authentication once, when setting up a tunnel, and then use bearer tokens from then on.

The session info in a browser is not persisted on disk as a long term config file that’s easy to copy and duplicate. Having a session key only ever exist in memory is completely different to storing WireGuard keys on a filesystem.

Edit: Also OpenVPN, which is the tool I’m comparing it with, only ever has session keys in memory. The 2FA part (password+OTP) isn’t saved by OpenVPN.

Typical session tokens shouldn't be valid for days, months or even years, unlike a straightforward wireguard setup.

The problem is that a Wireguard key isn't a session token -- it isn't revoked when the connection ends or goes idle. It's more like an authorized SSH key which in most environments meets the bar for 1FA even if it requires 2FA to set up the key.

WG has the concept of sessions already, the only change would be allowing a process in userspace to instrument the sessions directly without going through the key system.

The the default key-routing system would be just one method of issuing and managing sessions making the core protocol even simpler!

By sessions, do you mean the key agreement/initiation protocol, that is re-run every 2 or so minutes (with the keys having moderately overlapping validity)?

I think you might like something like Tailscale: https://tailscale.com/

It looks quite good, but I don't see any information on:

1. Is it open-source?

2. When am I going to see the "you have to pay us now" screen, and how much will it cost? I realize it's a business and am fine with that, but want to know what I'm spending before setting stuff up.

I am not affiliated with Tailscale, I merely know that it exists. You should ask them the questions for an authoritative answer.

> Wireguard needs to put actual logging into the product before anyone should consider using it in production.

The kernel already has this:

    # modprobe wireguard && echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

Then you'll get useful messages in your syslog.

Wireguard still has this warning on their site:

> WireGuard is currently working toward a stable 1.0 release. Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software). This text will be removed after a thorough audit.

It looks like they're saying that they'll switch to 1.0 when Linux 5.6 is released in a few weeks.

Right, that's the plan.

When can we expect interface and/or ip binding, and possibility to disable roaming?

IMHO roaming should be opt-in iif you specify the remote endpoint.

With that, Ubuntu Core 20 should be a brilliant fire-and-forget VPN server.

I'm excited for wireguard, but I'm not going to use it in production until the authors advise that it's ready for production.

Only out of abundant caution, it seems. I mean, Cloudflare is using it.

The author has specifically said it'll be considered released when it's in the kernel, which makes the parents point kinda mute.

https://grammarist.com/usage/moot-mute/

Cloudflare is not the golden standard for security.

Who is?

OpenBSD

I don't know a lot of serious systems security people who actually believe that. OpenBSD is fine, and smart people work on it, but it's been a long time since the early 2000's.

AFAIK it remains the single most selective platform out there. If a project is included in an OpenBSD release you know it has undergone serious whitebox scrutiny for security issues. I'm not aware of any platform that is quite so pedantic at the source code level.

And yet: https://news.ycombinator.com/item?id=22175431

I've said pretty much all I have to say about this, here:

https://news.ycombinator.com/item?id=7071219

What's the history there?

The protocol yes, but don't they use their own implementation? https://github.com/cloudflare/boringtun

Sure, but the underlying codebase hasn't had a public audit for boringtun or wireguard, so they're both in the same boat.

Cloudflare is also cautioning against using their own implementation in production.

Security people are always like that (I love that about them). They freak out if a hash function will now take 50 million years to find a collision on a supercomputer, rather than 345 billion. It's worked flawlessly for me and many others the past year in our production environment.

The fact that Ubuntu is including it, means that it's probably passed a critical mass of early adopters and then is probably seeping into the startup mainstream (as opposed to enterprise that wants 20 valid bells and whistles like authentication, auditing, etc).

The authors say that their current version(s):

> should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software)

I figure they know better than I do.

In ~2 months time Wireguard is reaching 1.0 along with Linux 5.6, I figure it's quite stable already and they say that (as anyone with a sane mind would) to keep their asses safe.

I also use it, and it works, but this tells us nothing about its actual security.

Security people are also subject to fads and fashion just like web developers or indeed any other technical group. Many will endorse the primitives developed for example by Dan Bernstein without understanding anything about how they actually work, or having read and understood papers describing their security. Just because he has some hacker "street cred" (arguably well deserved) as the developer of qmail, etc.

The primitives codesigned/codiscovered by Dan Bernstein have become popular not because of hacker street cred but rather because they are peer reviewed and have good design rationale

This is an extraordinarily weird way to summarize WireGuard's cryptography, which shares primitives with Signal (it's derived from Trevor Perrin's Noise framework) and, while we're at it, TLS 1.3. Bernstein's credibility in cryptography comes from his standing as an academic cryptographer, not as "the developer of qmail".

I'm not remotely a cryptographer. And I'm not saying there is anything wrong with his algos obviously. But I remember when the algos designed by Bruce Schneier were all the rage, and I think it was similarly based on some sort of guru status. If I look at Bernstein's most cited papers, they are all about performance, aside from what appears to be a survey on post-quantum crypto and what does seem to be like a well-cited paper on AES cache timing attacks.

So my genuine question is: does he really have an unusual academic standing as a cryptographer?

This ranking by citation (which appears to be up-to-date/live) puts him in position 62: https://kodu.ut.ee/~lipmaa/cites/cites.php?data=crypto

Granted, it's just a ranking by citation, and this definitely puts him in the top 100, which is nothing to scoff at, but I'm still wondering if there is a similar effect, and if in ten years we won't be using algos all written by some other guy because he's the new cool kid.

I feel like you've answered your own question.

Ah; maybe, yes :)

Not OP. I do not have issues with WireGuard's cryptography.

I do have issues with wireguard's security - things like silently accepting invalid configuration, changing one peer can silently affect another (only avoided via external means), roaming is default enabled and can't be disabled nor can you bind the tunnel to an interface or an ip, nor does it pad packets even the slightest to reduce "meta"data leakage.

Just because the cryptography is (probably) sane, doesn't mean wireguard as a whole is good for all or most use-cases.

I guess you're just left with no VPN software then? If WG isn't suitable for production, then OpenVPN, IPSec & co. definitely aren't.

I can only make informed decisions based on the information I have. I don't have the time or expertise to personally audit every piece of code I use. I have to leverage the available resources and evidence that others have put forward.

And all evidence put forward seems to suggest that all commonly deployed VPN solutions really suck. Do you simply ignore that evidence?

Known weaknesses are actionable. Unknown weaknesses are not.

Known weaknesses such as vast and messy codebases? What's the action there? A full rewrite?

Security is only considered stable after being consumed long enough without holes, so not sure how you're measuring it.

From the most recent wireguard-linux-compat release notes:

https://lists.zx2c4.com/pipermail/wireguard/2020-January/004...

> Please note that until Linux 5.6 is released, this snapshot is a snapshot rather than a secure final release.

In other words, over the next ~10 weeks, Linus' kernel tree and Dave Miller's net.git tree will fill up with nice stabilization patches. At the end of that process, 5.6 will be released. At that time, our backports to older kernels (wireguard-linux-compat) will also become a "1.0". This also lines up with the 20.04 LTS release and such.

FTR, WireGuard also available in F-Droid repo for all Android 5.0+ devices.[0]

> If your device has a custom kernel containing the WireGuard module, then the module will be used for superior battery life and performance. Otherwise a userspace version will work sufficiently on all other devices.

[0] https://apt.izzysoft.de/fdroid/index/apk/com.wireguard.andro...

For Google Pixel devices, we're actually prebuilding and distributing WireGuard kernel modules for use in that app:

https://github.com/WireGuard/android-wireguard-module-builde...

I'm assuming these modules require superuser access, correct?

Yea, kernel-wireguard on Android is just for people who have rooted their phones and want a little extra adventure. Cellphones have weird networking stacks and unusually written drivers (I'm looking at you, qcacld and rmnet_perf...), so supporting WireGuard's kernel module on Android has been very worthwhile to us for fine tuning things. Plus the performance is as good as can be in kernel space. But it's definitely something for "rooters only."

I'm sad that it doesn't support older versions... There are still many users on these devices.

What’s the best “WireGuard as a VPN configuration” doc out there? Many are not clear about what is being set up, why the cidrs are chosen, how it works without DHCP etc. other guides focus on only proxying rfc1918 traffic and not your entire connection. Is my DNS leaking? Is ALL traffic going through it?

OpenVPN, with all of its issues, is simple to set up in a way that’s not leaky.

The best is probably with network namespaces where you don't have network access by default, only wireguard has.

https://www.wireguard.com/netns/#routing-all-your-traffic

There's probably some guides out there.

If you put two /1 routes towards the private vpn endpoint and one route for your public vpn endpoint to your public ip it'll route all traffic over the vpn because it's the more specific route. The rest is your ip rules and your issue if you don't want any traffic in your physically attached subnet to go over the shortest distance. It's not really up to the protocol, it's the tooling around it.

While I love the product and use it in production, debugging is a royal pain in the ass.

There is zero logging to help understand when and how a connection is established (or not) server side.

Logging that someone tries to conne ct but wrong key, wrong protocol, whatever - that would help tremendously. Today it is tcpdump or wireshark all the way.

Could someone please explain what a meaningful example usage of WireGuard might be? The intro seems to imply something that could be duplicated with a terminal + SSH forwarding + a VPS. How is this better and/or different? Thank you :-)

I use it as an IPSec replacement for a site-to-site tunnel and to provide my phone a VPN connection to my home network.

Wireguard is much easier to set up than either IPSec or OpenVPN, and seems to outperform at least the latter.

wireguard is now available from android, ios to mac, windows and other platforms.

The iOS app is very bare-bones and it drops the connection once a day and doesn’t notify you about and doesn’t try to reconnect automatically. I hope Mullvad VPN will release their own app this year.

Is that limitation on the app side or OS side?

Has never dropped a connection for me. It always reconnects.

Reply on news.ycombinator.com