WireGuard 1.0 for Linux 5.6
lists.zx2c4.com
lists.zx2c4.com
Algo has built-in support for various cloud providers, where, when you run it from, day, your desktop, it can setup the VPN server for you based on answers to some questions (with sensible defaults) and some information on connecting to the provider (like an API key, for example). You also get QR code images that you can use to install a VPN profile on your phone.
You can also run Algo from within a server and have it setup the VPN for you.
Also, ty for "kiddiot" (much better than "script kiddie" term)
I don't think considering a VPS insecure is really that far fetched.
If you want to be secure against local adversaries, use TOR.
More specifically, it's begging the question. The actual definition of begging the question, not the mistaken usage.
To beg the question is to assume the thing which is to be proven.
begging the question as a logical fallacy is prevalent in politics and media representations, and is a differentiatior between reasoned debate and talking head nonsense.
Polictician 1: UBI! P2: free market competition! P1: why do you want poor people to suffer, P2?!
P2: 2nd amendment! P1: Ban firearms! P2: why do you want americans to be put in danger, P1?!
both of these are begging the question
If you dont want to trust them now, in 2020, don't - they aren't the only provider of VMs. I'd imagine the big cloud providers (AWS/GCP/Azure) have fairly significant security teams - has there ever been a disclosure of customer VMs being compromised on any of them?
Instead, you might get whatever elements of your identity stolen that Linode's account-management servers have possession of; or your VPS instance might become host to crypto-mining malware and then get shut down by Linode (which will come at no cost to you, other than the downtime.) But neither of these things will really focus on you personally. They're automated bulk attacks.
Whether that fits your security scenario is up to you.
If your primary goal is to get from an untrusted network (say public wifi) to a trusted network then a VPS with a provider you trust is great.
Not quite sure what you are asking about in this first part of your comment, but I'll get back to that.
Firstly though, I think I might see what you are getting at, but correct me if I am misunderstanding what you are saying.
> It's something I would want to avoid. (A VPS is a prime candidate to be compromised)
So, I think that what you are saying here is that by passing all of your traffic through a VPS that you set up yourself, you are increasing the attack surface that others have against you in a specific and potentially particularly dangerous way.
And to some extent I agree with that.
Unlike what the first one of the other commenters said in their response to you, I think you are not talking about state level actors. I also think that you are not talking about the VPS provider wanting to look at your traffic. I think what you are pointing out is that:
1. Keeping the operating system and services that are running on the VPS up to date with patches will be the responsibility of the person that is renting the VPS.
2. The VPS is more or less permanently connected directly to the public Internet. As such, it is under constant "fire" from automated attacks. (Anyone who has run a VPS or other server or device directly connected to the public Internet knows this to be true. It doesn't matter how big or small you are, or who you are.)
3. As a consequence of points 1 and 2, failure to keep the OS and services patched could result in compromise of your VPS. (Most likely the purpose of the compromise is that the attackers want to use the machine for things like having it participate in DDoS attacks, sending spam, compromising other actually valuable targets, or mining crypto currency. But it can indeed not be ruled out that they would potentially listen in on the traffic you are passing through your VPN on it also. And even if most of the criminals don't care about the VPNs running on the compromised servers today, they might in the future. Especially if there is a common wide-spread VPN configuration that a lot of the compromised servers are all running, so that they could mass-intercept all of the data on all of those compromised servers with little work/effort on their part.)
If that is what you mean then I agree that it might be a problem.
Compared to professional VPN providers, any individual renting a VPS is probably comparatively less skilled at keeping their VPS secure than the VPN provider is at keeping the VPN service secure from external attackers. And even if someone has all of the skill that they need to securely configuring their VPS and keeping it up to date with patches, they still have far less time on their hand available for auditing, monitoring, and all of that, than all of the people that are being paid to take care of those things at a large scale VPN provider with many employees.
So again, that's another point that I agree with you about if that is also what you mean.
At the same time, however, it should also be pointed out that it can be really hard to know who the people behind any particular VPN service provider is. But the same argument applies against a lot of the VPS providers out there.
Any random VPN service provider could claim that they have a big team, that the service they are offering is secure, and that they don't keep logs and don't record traffic. But at the end of the day for most of them, you have nothing more than their word to go on.
The same applies to random VPS providers though. With most of them you have no idea about who they are and what they are actually spending their time doing.
Sorry my comment is getting real long and yet there is more that I would like to touch on.
For example, another point in favour of the argument that I think you are making is that potentially, VPN service providers are monitoring their whole networks of hosts specifically for attacks that seek to intercept the traffic of their customers, in addition to the regular type of attacks that all hosts on the internet are subject to.
Whereas with a VPS provider, I imagine that they are primarily monitoring for the regular type of attacks mentioned before. VPS providers will notice, and shutdown VPSes that have been compromised if those compromised machines are participating in DDoS attacks on other hosts, sending spam, or burning too many CPU cycles as a result of cryptocurrency mining malware having infected them. But unless notified by one of their customer about the specific type of attack where data is being exfiltrated or tampered with on an infected VPS itself, most VPS providers would be unlikely to notice such a type of attack I think, and furthermore I think this is natural to expect. After all, when you rent a VPS, you are specifically paying the company for the privilege of you being in charge of what that VPS is doing, and for them to largely stay out of and away from your VPS itself, no? At least, that's the way that I think about it. As long as the VPSes are not consuming excessive amounts of resources and not being disruptive or malicious towards external hosts, I think both the VPS companies and their customers expect the VPS company to not interfere with what the VPS itself is doing, and to not be surveilling the processes, disk and memory of the VPSes. It's a virtual private server after all, right?
So that's another point for the argument I think you are trying to make.
But I don't see VPN service providers as being much safer as a whole. I think it is highly probable that among all of the companies that provide VPN services, it is likely that a significant portion of them are straight up malicious. By that I mean, they say they don't look at your traffic and they say they don't keep logs. But for all we know, and given the fact that many forms of cyber crime is profitable enough that criminals are engaging in it, I think it is reasonable to suspect that quite a few of the providers are mining your data or worse.
This brings me back to the first part of your comment, which has me confused about what you mean.
> Does the VPS have unencrypted access to the VPN?
Confused because yes, this is how any VPN works. You get an encrypted link between your device and the other end of the VPN connection. The VPN connection extends only to the VPN server/gateway that you connected to in the first place, no matter if that is some VPN server you are running on a VPS yourself, or if you are paying a VPN service provider for it.
The extent to which your data is encrypted or not all the way to the final destination will be entirely dependent on what kinds of traffic your device itself is sending in the first place.
If your device is tunneling unencrypted traffic inside of the VPN connection, then unencrypted traffic will be what comes out at the other end where the VPN tunnel is terminated. There is no way around that. The only thing you can do, is to ensure that your device does not try to send that kind of data through the VPN in the first place, if you are concerned about said traffic being visible at the other end of the VPN tunnel.
The use case I was referring too is where the VPN is between e.g. your corporate network and your pc when working from home. In this case the VPS doesn't need to see the unencrypted traffic.
A sibling comment made clear that the ansible recipe mentioned is to setup a VPN between e.g. a laptop in the VPS.
Your corporate IT should be providing you with VPN access directly to your corporate network. You should not be using a private VPN in addition to using your corporate VPN when working.
A VPN on a VPS would be ONLY for personal use (unless of course you are self-employed, the business owner, an independent contractor, etc.).
I would review your IT policy, you are probably breaching your policy if you are using a company owned machine to connect to your private VPN on a VPS.
Its secure defaults will probably block all other services you're running on your server and render them inaccessible.
You might even end up not being able to ssh to your server if you choose not to let Algo set up ssh configurations (because you have your own).
I would say install Algo on a dedicated droplet or backup your VPS before setting it up.
If you are running other co-resident services and need more lenient firewall rules / system configuration, you should consider another option.
droplet == host?
"Niche" is a bad way to describe Arch.
It's probably more likely that a person interested in setting up WireGuard and their own VPN are running Arch or a derivative than any other distro.
Mostly I was responding to the statement that Arch was a niche distro.
This lets you configure it with stuff like systemd-networkd and unit files, or easily spin up a tunnel with a few `ip` commands, and setup some simple nftables rules to do all sorts of stuff.
I do use it as a vpn as well, but it's so much easier to setup than, say, OpenVPN, where you need to create tun/br interfaces and then tie them together with a service, etc. That said, OpenVPN and other actual VPN software does more than just a tunnel (like pushing routes, config settings, etc), so WireGuard cannot replace everything by itself.
The documentation is rather sparse, but there isn't much to it either. The manpages have what you need to know and the rest is just general Linux network stack knowledge.
It can be used to replace flannel if encryption in transit is required.
I like that idea, because it means that the actual WireGuard core is small and it's usable right now. It is annoying that someone hasn't yet developed neat integrations for WireGuard and stuff I might want to use, but — I'm someone! I (or you, or whoever) can build something, and as surely as day follows the night someone else will build some neat things in the future.
It's early days yet!
ip link add wg0 type wrieguard
ip addr add 10.1.20.1/24 dev wg0
wg set wg0 listen-port 5100 private-key /etc/path/to/key
ip link set wg0 up
wg set wg0 peer........
It's great when you're just trying to test things out. You can do a lot of stuff by hand, make sure it's working, try the conf file, enable the systemd or runit service, reboot and make sure it comes up.
It's a huge hassle to take that box down, spin up a new instance in Singapore, distribute profiles and authenticate. This is neither Algo nor Wireguard's fault. I just wish we had some more tooling to make it easier to move between instances.
(I'm in no way affiliated, but stumbled upon it on twitter a few weeks ago)
He's asking for a central server where he can retrieve/update/manage end-user keys, likely: because helpdesk.
You could in theory do this with any number of the existing team password managers, but I think he'd like integration directly to wireguard.
Edit: care to reply rather than just downvote? All of their documentation and examples state exactly what I'm saying. They're turning all the devices into endpoints and creating a mesh - he doesn't want users bypassing his SINGLE VPN endpoint into the company or talking directly to each other based on his description. He wants Cisco Anyconnect - only wireguard.
https://news.ycombinator.com/item?id=22665589
It doesnt look like a nail/hammer/screw at all. Tailscale isnt configured how he wants out of the box, but using SSO to control access isnt a massively complex hurdle. Anyone with Office 365 will be able to use their Office account to authenticate, which is basically Cloud Active Directory, and way better (if its something you have) than maintaining a separate username/password database for the VPN.
ACLs and a relay node are a good fit for the request. https://tailscale.com/kb/1019/install-subnets
Cloud SSO might be a deal breaker, but it doesnt make the solution the wrong class of solution.
Building on what katnegermis said, this is what we're trying to help with. We integrate with identity management systems and handle the key management (and NAT traversal) on top of WireGuard, making it easier to deploy and manage.
If you're interested, a colleague of mine wrote up a blog post on how things work: https://tailscale.com/blog/how-tailscale-works/
> Log in with your Gmail account
HHNNNNNNGNNGNGNGNGNGNNGNNN ....
> look around a bit more
> no mention of license
is this proprietary software? lol no thanks, keep it.
Then I would use it for my family, e.g. I could replace DynDNS + port forwarding I set up so my dad can control his home automation software (Hass.io) from his iPhone app, even off the WiFi. I’m unfortunately just not willing to set up/shell out for GSuite/Active Directory/Office365 for my family.
What really hooked me was your story about the medical practice a little while back.
It is extremely refreshing to not have to deal with key/certificate management, and to have all my VPN traffic be directly client to client instead of via a slow (or expensive) and likely remote VPN server.
Great product and I can't wait for some time to play around with it further!
It would be great if Tailscale had its independent 2-fa that I fan use through any hardware key (for compliance reasons), rather than go through Google.
So why is it so much better?
Is it because it's a new and simpler implementation than what we have for IPSec?
Is it because the protocol, being newer, is simpler and cleaner than IPSec?
Is it because, being newer, it can use a modern ciphersuite?
Are there fundamental advances in the design?
One of the nice things about IPSec is that it's a standard. There's a reasonable chance that two endpoints written by separate parties will be able to communicate. Introducing a whole new protocol whose main implementation is its definition seems like a step backwards.
Having deployed IPSec between vendors, this is only "sorta" true. IPSec can be an immense fiddle to actually get running between two vendors for the first time.
One of the other issues when using IPSec between vendors (or even just be default) is that the actual overlapping ciphers/hashes that are supported or even just work are normally the lowest possible.
> Are there fundamental advances in the design?
First party roaming makes dealing with mobile and CGNAT much nicer, anyone behind a IPSec VPN on a home CGNAT network will have a bad time (often it won't connect at all)
Finally. It's code base is actually pretty small, allowing sane audits to take place. In my eyes thats a huge win. People who have seen the sheer size of strongswan or openvpn might appreciate wireguard in comparison.
I would love to agree with this, but in practice, IPsec across vendors (or even across product lines from the same vendor) is often a nightmare. There are so many moving parts to IPSec, whereas Wireguard is drastically simpler.
I've been using / working [1] [2] with strongSwan since early 2014, admittedly, the hands-on experience lifted my Linux / Networking skills to a whole new level, but at cost (countless hours burnt). It requires a broad range of skills, has a relatively steep learning curve.
> The company I've worked for (in pre-IPO stage), had 800+ strongSwan instances served as site-to-site VPN gateways inside AWS VPCs, they were single point of failure from a design PoV but that simple design (with health check and recovery mechanism of course) worked surprisingly very well over a period of 3 years (thanks to simple design and stability & quality of strongSwan). Personally I've been using strongSwan based VPN gateways to punch holes in GFW and encrypt network traffic until mid 2018, happy with it (<10 strongSwan instances to manage).
WireGuard is totally different design when I first migrated from strongSwan, simple, visible (interface, route-based), cryptokey routing, built-in roaming, small code base (minimal attack surface), performance (in kernel). Over time scalability and usability (all sorts of web UIs or GUIs) will improve, for large scale overlay we may better off with something else (nebula). For now officially it offers native client for most of the popular platforms.
For any new typical VPN (remote access, encryption in transit, site-to-site may not be as flexible as IPsec as I haven't done that, I used nebula instead to created an overlay) use cases, I'll pick WireGuard to start with ;-)
Will WG make a marked difference in stability, speed, approachability for normal users, or what can we expect?
Compared to the 80% use case of OpenVPN, Wireguard is:
1. Much less code. A few thousand lines of code vs lots more for OpenVPN
2. Speedier. WG does UDP traffic so there is less overhead on the protocol level for syncs acks etc.
3. Easier on mobile battery life due to decreased complexity
For one example use case comparing them side by side, see PiVPN, which I use to setup a Raspberry Pi Zero W on my home network, create a client key for my phone, open a single port forward to the pivpn server, download the wireguard app, scan the qr code the pivpn key generated, and poof, I can check a box and 'be' on my home network, behind my pihole, and with access to my LAN resources.
OpenVPN can do that usecase with pivpn as well but its more processor intensive and a little more setup vs wireguard.
A lot more! PKI infrastructure, chiphersuites and so on and so forth...
By the way OpenVPN also can work with UDP, even it's default mode.
For instance pfSense provides you with single-click configs for any target platform, with certs, credentials etc. properly tied to some ACL or ID management system, etc. It's neat and pain-free and just works.
You could learn all the theory underneath (I mean systems, IT, not the crypto!) and do it manually (and you probably should for a big-enough infra, or specific-enough use-case), but that will be premature optimization I think.
Basic VPN is easy (take a weekend to learn / implement and you'll have all the great benefits of VPNs). Wireguard is "just" more efficient by an order of magnitude as I see it, it'll become the de facto low-profile implementation me thinks.
We might not be using the word "manual" to mean the same here.
I meant not writing the whole xml json yaml or whatever yourself, manually copying certs and credentials etc — you're likely to make mistakes, it's tedious and useless most of the time. You rather use tools like Viscosity. Just efficient / best practice sysadmin.
You obviously need access to the target machine in the first place... it's a VPN setup.
Was it worse than you would expect? Worse than say openvpn or wireguard-rs/wireguard-go?
What about encrypted TCP? Do they block/throttle everything but web and recognized traffic? If that's the case wrapping WG or ZeroTier or whatever in TCP would do nothing since it would still look like a weird unrecognized protocol with a max entropy (encrypted) data stream.
I also discovered Wireguard cannot bind to a specific adapter or IP address if you have multiple address on a server. That might not seem like as a big a deal since it only responds to fully authenticated packets, but it does mean that outgoing packets could be leaving from a different IP address than incoming packets.
It's weird that something that's now making it into mainline can't do this very simple kind of bind that almost every other userlevel service, and OpenVPN, can do.
I did not test IPSec vs WireGuard, but scp from/to my home router/NAS is about three times faster with AES (used by IPSec) than with Chacha20 (used by WG).
I have no idea what was going on, but wireguard and IPsec was comparable in that test, with ispec being sliiiightly faster. the network has almost no latency, so if the retries remain on slower networks, that would change.
FWIW the userspace implementations are quite good, and still out performs IPSec.
But the 'not invented here' syndrome is very real.
Apple would need to do the XNU work since their open source model is so broken, and they seemed to have deprioritized Unix nerds awhile back so…
[1] https://github.com/place1/wg-access-server [2] https://place1.github.io/wg-access-server/
I was looking for something like wg-access-server web UI when moving away from strongSwan. Found Subspace but id didn't work the way I wanted, settled pretty well with some shell scripting for my own use cases and happy lol
I think wg-access-server makes a lot of sense to people who want to self-host VPN on cheap VPS like Vultr or DigitalOcean, Lightsail, etc., it is simple, easy to deploy and use, flexible and scalable (if deployed to k8s).
I like how their official tutorial video shows all the raw ip commands and then shows their wg-quick configuration script. That way you understand what the script is doing and what commands its running.
One big limitation is that it cannot bind to a specific IP address. The author states it shouldn't matter because it won't respond without the right auth key (and it doesn't support TCP so people can't tell if it's sitting there listening) but I found I did get into weird routing loops where packets will come in on one IP and go out on another one. The primary outgoing IP is what shows up when you run `wg show`.
It is super weird to implement a brand new service and have a config option for the port, but not the IP address(es) to listen on.
That's good to hear, but how does it handle authentication / authorization?
I literally can't replace any VPN I currently use with Wireguard because I would lose needed functionality. I could maybe replace the tunnel to a bastion host, but even then I would actually be worse off security wise, because I'd be losing cert-based key management. (ex. https://smallstep.com/blog/use-ssh-certificates/)
Wireguard was too alluring to not try though, and now I really like it. I would like to move away from my homemade pull, build, and install scripts, but not for any good/justified reason. I suppose I just like the idea of someone being responsible for a software stack that I rely on.
arch is on 5.5.6 as of 3/1/2020 (https://www.archlinux.org/download/), and it seems like the ARM porters are pretty good about keeping their project in sync (two day delay): http://de3.mirror.archlinuxarm.org/os/rpi/.
My best guess is that by April or May, Arch will do the minor version bump, and then a couple days later Arch ARM will get it.
It doesn't have the same hardware/software synergy that you like, but it might be a fun weekend experiment.
I would guess that we'll get 5.6 in the coming days.
Is the main download page the rough equivalent to `master`, and your link is like the feature branch for merging the latest kernel version into the distro?
That makes perfect sense, actually: no sense crippling install the .iso with (potentially) unstable program versions, to stymie the install process.
I've been using WireGuard to replace IPsec (strongSwan - the whole stack is way too complex, plus client configuration issues, outweighs the benefits) and OpenVPN (latency, bandwidth / performance is the biggest complaint) for remote access and mainly encrypting traffic from/to terminal devices when accessing the Internet via unknown hops/routes/path.
On the other hand, WireGuard is simple (cryptokey routing), modern, elegant, easy to configure & use, fast, and most importantly, reliable over the past 2.5 years, now even better without DKMS headaches ;-)
WireGuard clients for iOS (works as good as strongSwan for Android - which I missed a while ago) in terms of 1. on-demand 2. roaming between networks 3. power consumption / overhead. macOS and Windows ones also work very well.
Problems: WireGuard does not scale well when used for global overlay network use cases (nebula does a much better job for this purpose). Another issue for VPN providers: each client has a static IP configuration, which contradicts with privacy and surveillance, curious to see how Cloudflare's 1.1.1.1 solves the problem.
Last but not least: WireGuard protocol is easy to block. Therefore, I look forward to seeing obfuscation plugins / extensions for WireGuard, it will serve a much bigger purpose for people who live under censorship/surveillance (e.g. inside GFW) so as to protect privacy and get back their rights to access the `real` Internet.
Many thanks to Jason and the WireGuard team behind the scene!
Your second point: Obfuscation protocols can encapsulate WireGuard just fine.
I have been running 2 simple standalone WireGuard VPN servers for remote access and encrypting traffic (2 EC2 instances inside a VPC, scripted configuration). Admittedly I didn't dig deep enough to think about or leverage VPC's DHCP and/or DHCP servers running on other EC2 instances in the same VPC over the last 2+ years (facepalm), which also means, WireGuard has been set & forget (reliably working ;-)
Will dive into obfuscation and compare with (known to work) solution V2Ray (WebSocket + TLS + Web) / Trojan for next battle with the GFW.
BTW: Gravitational has built a WireGuard based overlay network CNI for k8s called wormhole [1] which can be used to replace flannel when encryption is required for in-cluster traffic across the overlay.
In the meantime, can anyone recommend a obfuscation proxy for Linux?
Could go very far with trivial functionality, such as listing, adding, removing users and download a config file/qr-code.
[1] https://github.com/pivpn/pivpn/tree/master/scripts/wireguard
It was featured on Show HN but did not get enough traction.
https://github.com/pirate/wireguard-docs#wireguard-setup-too...
Can someone explain why we need/want to put it into the Linux kernel?
This is about the code being merged upstream into the main kernel repository which means that it'll likely be built-in to lots of distribution kernels and will no longer have the second-class status that most out-of-tree kernel modules have.
Wouldn't Wireguard work with a simple shared secret on both ends?
Great to see 1.0.0 released. I’ve been using it for a VPN to my home network and have been really impressed with how fast it is (and how fast it connects!). The corporate VPNs I’ve used in the past we’re so much slower that it feels like a completely different league, although they support many more features of course.
I advise you to try it on mobile devices or with unstable interested. It's a miracle!
For real world use, I'm a fan of https://wiki.debian.org/Wireguard
There are a bunch linked from the links section at the bottom.
I've used a ton of VPN over the years, even some I wrote myself, and I've never seen anything that comes close to wireguard in terms of: ease of use, speed, cleanliness of code.
The world just got a whole lot secure and flexible.
(Via https://news.ycombinator.com/item?id=22731279, but no comments there.)
Much better documentation is here: https://github.com/pirate/wireguard-docs
If you can't trust a VPN provider for some reason or are trying to secure a route to a specific network, setting it up yourself starts to make sense.
WireGuard is not only about that. Sure you could do it. But it is applicable for any use-case where you have two or more machines that need to talk over a secure tunnel, over an otherwise not proven to be secure network(which is usually, but not always, the Internet). This ranges from connecting to a machine you have at home, to exchanging data between two office branches, and so on.