For anyone wanting to try it, WireGuard with Algo VPN [1] to set it up on a server is a great combination. I found it quite easy to setup and use.
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.
I id have some problems with algo behind a NAT. Though my usecase is a bit different, more of a road warrior, as I wanted to be able to access a server in one property (behind NAT) from my home PC (also NAT).
I suppose I just need port forwarding.
WireGuard is great, but I think it's really undersold when it's described as being just a vpn. It's really an encrypted tunnel that is configured like a network adapter in the Linux network stack.
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.
Is there an application for containers? E.g. a way to set up an encrypted tunneling interface between containers that would allow you to avoid using TLS between the containers?
One thing I wish for wireguard: the ability to look up keys/ips in an external system like LDAP. I moved an entire call center [50+ people] fully remote last week. We're using wireguard. Key management stinks, and that is my only complaint! It is an incredible piece of software and I'm very thankful for it.
I'm a bit baffled by WireGuard. From 10 000 feet, the protocol is similar to IPSec - encrypt packets, and send them over the internet using a connectionless protocol.
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.
> 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.
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.
IPsec is industry standard, but the whole IPsec stack and surrounding technology stack are very complex, different implementations (e.g. those Swans), configuration combos (phase 1,2 or in strongSwan sense - IKE, ESP, route-based, policy-based, etc.) and clients for different platform makes the whole thing a headache to deal with at large scale.
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 ;-)
> One of the nice things about IPSec is that it's a standard
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.
From what I understand, Wireguard is intentionally non crypto-agile. Wireguard 1.0 has a mandated cyrpto suite, and in the future 2.0 or 3.0 would have mandated standards as well. As a result the connection negotiation is simplified and interop is guaranteed between providers.
Given the occasion, could someone write a paragraph about what downstream effects are expected by wireguard existing? So far I’ve seen mostly technical arguments for it. VPNs have become a more important piece of infrastructure now. The most significant approachability increase really came from mobile based solutions and auto pilot systems like Google’s Outline.
Will WG make a marked difference in stability, speed, approachability for normal users, or what can we expect?
Someone else can give a much better comparison than me, this is just to get you started.
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.
Anecdotally: I have run ipsec based VPNs, openvpn, SSH tunnel based VPNs, etc. Almost all have been a bit of a PITA. I walked someone through setting up a WG based VPN two weeks ago, at a wework in Jakarta. Took 10m via slack. The machine is behind a NAT and I haven't had a single problem connecting. I've done tests where I rolled a new server and as soon as it was up, the tunnels were back. It's a thing up beauty.
I really hope WireGuard becomes a standard and get's included in the macOS/iOS and Windows kernels as well. Key management and and other fancy features could be left to userspace applications but having the basic wg capability in the kernel would be great.
I'm a big fan of Wireguard. I wrote wg-access-server [1] as an all-in-one wireguard VPN solution. I recently added some docs [2] and support for deploying with Helm. I'd love some feedback on here or on github. Give it a try.
I recently setup WireGuard on my new dedicated server and it is amazingly easier compared to OpenVPN. I've setup several site-to-site and client-to-site VPNs on OpenVPN so maybe I'm just use to all the iptables/route gotchas, but not needing to do the whole CA/easyrsa stuff is a huge bonus.
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.
I like the idea of WireGuard as a simple tunnel, but I wish people would stop comparing it with VPNs. VPNs have lots of extra functionality that is necessary to support a variety of use cases, both functionally (like pushing routes or scripts to clients) and security-wise (like real key management and SSO).
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/)
Now I really want to know when raspbian will get linux kernel 5.6. The most recent version of raspbian came out in February 2020 and uses linux kernel 4.19, which came out in late 2018.
it can actually work with 4.19 and the unstable repo.
I'm using 4.19.105-v7+ (to solve a macvlan bug in the default .97 and it works.
It's a pain to install the headers on raspbian though
Very exciting news, indeed! Finally WireGuard is in the Linux kernel 5.6 onwoards (will arrive soon in the next few days for those who are on rolling releases).
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 first point: There's no part of WireGuard that inherently demands the use of a static IP address. You can run whatever dynamic IP protocol you want inside of it or outside of it. The entire interface configuration is dynamically configurable at runtime. We're working on one called wg-dynamic, but others have done others.
Your second point: Obfuscation protocols can encapsulate WireGuard just fine.
Any ideas how to get a client-server style VPN setup with WireGuard working with IPv6 so that it keeps working even if the public IP address of your VPN server changes? The configurations I've seen assign a statically configured IP address to a client. This works fine with NATted IPv4, but with IPv6, addresses are "public", so the client must basically know the prefix of the server to be able to configure a sane address, and if that changes, the configuration must be changed by hand.
The PiVPN project makes installing / administering WireGuard on the raspberry pi super easy - it has some scripts that nicely wrap WireGuard [1]. I'm not sure how generally applicable they are, but it might be a good starting point.
WireGuard on Linux has always been implemented as a kernel module (a very small one at that). If you've used it on Linux, you've used the code that has been included in Linux 5.6.
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.
The version you've been using on Linux was already in the Linux kernel. It's a Linux kernel module. Now it's just part of the official Linux source release, so groups like Linux distributions such as Ubuntu will start turning it on by default.
If you've been using it on linux, you've almost certainly already been using the kernel version. Anecdotally, using it on my home LAN, the kernel implementation on linux performs much better than the userland implementation on MacOS. (Admittedly not the same hardware, the linux machine is a i5-3427U while the MacOS machine has an i5-5250U. I think the former might have an L2 cache advantage, but I'm not sure if that would explain the difference.)
Could WireGuard be a good choice for server-to-server encryption instead of TLS? (for example between a TLS terminating load balancer to the application servers)
What net benefits would you see that having? If I'm allowed to assume that you wouldn't use TLS because of PKI management concerns, I have a hard time seeing how using WireGuard in the large wouldn't have the same problems--you still have to build some kind of management platform on top that verifies host authenticity (ultimately including revocations and more). That is to say, WireGuard in the large will surely (right?) need supporting PKI.
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.
[+] [-] newscracker|6 years ago|reply
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.
[1]: https://github.com/trailofbits/algo
[+] [-] wisam|6 years ago|reply
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.
[+] [-] Diederich|6 years ago|reply
[+] [-] mcdevilkiller|6 years ago|reply
[+] [-] rubenbe|6 years ago|reply
[+] [-] dzonga|6 years ago|reply
[+] [-] kaylynb|6 years ago|reply
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.
[+] [-] DaniloDias|6 years ago|reply
[+] [-] exabrial|6 years ago|reply
[+] [-] twic|6 years ago|reply
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.
[+] [-] benjojo12|6 years ago|reply
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.
[+] [-] terrywang|6 years ago|reply
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 ;-)
[1]: https://news.ycombinator.com/item?id=13654412
[2]: https://news.ycombinator.com/item?id=13434417
[+] [-] neilalexander|6 years ago|reply
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.
[+] [-] seanalltogether|6 years ago|reply
[+] [-] xal|6 years ago|reply
Will WG make a marked difference in stability, speed, approachability for normal users, or what can we expect?
[+] [-] myu701|6 years ago|reply
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.
[+] [-] igetspam|6 years ago|reply
[+] [-] kertis|6 years ago|reply
[+] [-] lifty|6 years ago|reply
[+] [-] donaldihunter|6 years ago|reply
[+] [-] kitotik|6 years ago|reply
FWIW the userspace implementations are quite good, and still out performs IPSec.
[+] [-] place1|6 years ago|reply
[1] https://github.com/place1/wg-access-server [2] https://place1.github.io/wg-access-server/
[+] [-] djsumdog|6 years ago|reply
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.
[+] [-] peterwwillis|6 years ago|reply
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/)
[+] [-] rasengan|6 years ago|reply
[+] [-] willis936|6 years ago|reply
https://en.wikipedia.org/wiki/Linux_kernel_version_history
[+] [-] kbaker|6 years ago|reply
https://www.kernel.org/category/releases.html
[+] [-] nick2k3|6 years ago|reply
[+] [-] Medicalidiot|6 years ago|reply
[+] [-] terrywang|6 years ago|reply
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!
[+] [-] zx2c4|6 years ago|reply
Your second point: Obfuscation protocols can encapsulate WireGuard just fine.
[+] [-] GolDDranks|6 years ago|reply
[+] [-] Znafon|6 years ago|reply
[+] [-] kertis|6 years ago|reply
[+] [-] tjoff|6 years ago|reply
Could go very far with trivial functionality, such as listing, adding, removing users and download a config file/qr-code.
[+] [-] BrandoElFollito|6 years ago|reply
It was featured on Show HN but did not get enough traction.
[+] [-] djclay|6 years ago|reply
[1] https://github.com/pivpn/pivpn/tree/master/scripts/wireguard
[+] [-] angristan|6 years ago|reply
[+] [-] laktak|6 years ago|reply
Can someone explain why we need/want to put it into the Linux kernel?
[+] [-] cyphar|6 years ago|reply
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.
[+] [-] cjbprime|6 years ago|reply
[+] [-] ac29|6 years ago|reply
[+] [-] catalogia|6 years ago|reply
[+] [-] mikepurvis|6 years ago|reply
[+] [-] borplk|6 years ago|reply
[+] [-] kasey_junk|6 years ago|reply
[+] [-] jblwps|6 years ago|reply
[+] [-] pkrumins|6 years ago|reply
[+] [-] ur-whale|6 years ago|reply
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.
[+] [-] samgranieri|6 years ago|reply