As someone who regularly deals with IPSec in conservative network environments, Wireguard can’t gain broad adoption soon enough, in my opinion.
Now that it’s merged into Linus’s tree, any word on it getting an official release and the “this isn’t production ready, so no CVEs” disclaimer going away?
EDIT:
Further back in the thread, Donenfeld says “Please note that until Linux 5.6 is released, this snapshot is a
snapshot rather than a secure final release.”, so perhaps real soon now?
That ( https://www.wireguard.com/donations/ -- repeating for completeness and exposure) is surely much better link for donations, as some of us would feel limited with a single "Patreon" option.
Any way you can add a "choose your amount" box on patreon, or a lower amount? I try to drop micro-contributions with creators via patreon and $15 is above the current budget for something I don't (yet?) make much use of.
I finally emailed my bosses asking our company to give about 100$ a month spread over various projects. I thought not to ask too much as 100$ infinitely much more than 0.
We're not a very big company, could easily afford 1k a month though, but then it becomes an actual sum that's harder to motivate as we're mainly working with MS products.
The problem I ran into is that my company will match employee contributions to registered non-profits. Wireguard doesn't seem to be a project under a registered non-profit. My company won't donate to a random Patreon or PayPal link.
There have been numerous threads here on HN about this: donating to people to support open source development does not match up with what companies usually do, so it runs into all sorts of corporate friction. Whereas a monthly or annual support contract is the sort of thing that companies do all the time, and at low dollar amounts it might not require much approval at all.
Unfortunately it is up to open source developers themselves to set their business model, and many don't seem to like (or want to do the work of) setting up overtly commercial relationships like support contracts.
I do rely on Wireguard for some personal projects and I can spare a few bucks. However the reality is I can't get to $15/month the minimum tier. I rely on thousands of opensource projects.
Upstreaming should help my arguments for adoption at work; they wouldn't think twice.
You can support on Patreon for less than the minimum tier. It is just the cut-off over which the rewards (such as stickers here) are given. Support for just $1! He'll still get it!
I didn't know this either. I guess that's why many projects have a fake $1 tier with just "the pleasure of knowing you contributed" or something like that as the "reward" for that tier. To let people know that that's still an option.
I agree, I would have signed up for a $1 tier or perhaps $2 but $15 is far too high for the minimum tier. I support the Zig author for $1/mo and hope others would do the same for my open source projects in the future.
Apart from knowing that 15 USD monthly is not a minimum possible donation there, please see other possibilities to donate on the official link for donations (also posted here). Patreon is only one of the options.
The minimum donation in Bitcoin is probably about US$0.01. Anyway that's what I've paid in transaction fees the last few times I made a donation where I didn't care how long it would take. (They were confirmed within a few hours.) Transaction fees for within-the-hour confirmation are around US$0.20.
it seems there are confusing / multiple sources of income, patreon is only one.
I don't know if it's fair to say he's not making what he asks for.. or basing a 1/10th claim without knowing how much he gets from other sources. (Bronze/gold partnerships GitHub donations, stripe, crypto donations, and some others).
Right. We'll stamp a 1.0 on the backports as soon as 5.6 is released and goes through the normal mainline release process. Stamping a 1.0 on the compat backport before mainline would be premature, but doing it the day of is the plan.
The over-summarized version is: IPSec is extensible and it's rather tedious to get every implementation to interoperate securely with every other implementation simultaneously (and in the correctly secure way).
While using IPSec between supported devices, in an ideally configured setup, yield slight but real benefits with respect to attack resistance, a practical comparison of the difficulty involved and possible configuration mistakes makes other solutions more robust and less likely to be used incorrectly.
This discussion covers most of the high level points, however it doesn't consider that Wireguard being adopted in 2020 and not 1995 means we've got 25 more years of public cryptography research and far more relevant defaults to include as the base of the standard.
The 1995 is a little unfair to the current IPsec: The complicated part of the protocol had a compatibility breaking & simplifying major revision in 2005 (IKEv2).
I think the main reason of the less than polished IPsec experience is that operating systems didn't really promote it as a out of the box working feature, but instead just offered APIs that were mainly used by corporate VPN product vendors who didn't really want interoperation except as a checkbox feature. The early interop hassles are just a symptom of lack of testing and effort - when vendors are motivated and actually everyone's implementation of a standardised protocol to interoperate they organise interoperation testing events etc and make sure their products ship with configurations that actually do interoperate in the real world.
Your linked StackOverflow answer muddies the water too much - IKE was always the official keying protocol[1]. Yes you can use lower level IPsec parts without it with manual keying if you are a masochist or have a very simple topology (like a 2-host tunnel with static IPs), but the other keying methods are fringe or academic.
[1] IKE was finished later than the lower level parts of IPsec, technically there was a period in the beginning when it didn't exist and you had only manual key setup
Well, the main advantage of WireGuard then seems to be it doesn't give you any options, so you're less likely to mess it up. Of course there is only one (two?) implementation(s) of it, so "interoperability" as such is not really a thing.
IPsec can be/is complicated because we learnt as we went with it, but given the correct settings, it can be/is secure.
So just like with SSL/TLS, it may be necessary to 'simply' introduce new RFCs to deprecate the Bad Way(s) of configuring it. Doing a quick search, there's a BCP RFC:
I’m using WireGuard daily on Linux and iPhone. It’s hard to describe how much better of an experience this is than OpenVPN. Connections are reliable and durable, latency is pretty low, and you can actually understand the software.
I also do this, but with Linode. The only hangup I hit every once in a while is that some services will block access to VPS IP blocks due to spam/malicious traffic. E.g. occasionally I can't get Google search results while on VPN, or Pokemon Go won't connect as they block VPS providers to prevent spoofing.
I see a lot more capchas which is annoying. Also paypal doesn't seem to work most of the time either, which is lame, as I use 2FA for any paypal transaction
Do you have any issues with sites blocking the DO IP addresses? I ran this for a while and a number of sites block connections for coming from a data center.
If you want to set up a VPN from a VPS, consider something like LunaHost, it's what I use and I find less issues with it due to being far less known I'd guess.
I can’t install the official WireGuard on my Macs that are stuck on High Sierra. Love WireGuard for Android and iOS. I think there’s a way to do it on High Sierra with brew but I haven’t dug too deep.
It sucks. It doesn't work on Windows reliably. If you're going to do VPN on Ubiquity gear I either install OpenVPN on the EdgeRouter or pass the traffic through to another device to handle the VPN.
Same but Linux and Mac. I have the feeling that online live conferences/meetings are working with Wireguard very good. With OpenVPN I always had the feeling to turn the VPN off to reduce the latency overhead.
I can’t install the official WireGuard on my Macs that are stuck on Sierra. Love WireGuard for Android and iOS. I think there’s a way to do it with brew.
I’ve been playing with wireguard for the past few days for my personal network. It is likely that I just don’t know what I’m doing yet, but I’ve been having connection issues that I haven’t had with openVPN. One set of issues is from overlapping IP ranges (192.168.1.0/24 is bad news) and another with something I haven’t figured out yet when connecting from work. OpenVPN doesn’t have issues but wireguard does. My thought is the specific port is filtered by my work, but I’m using a rather obscure and high value port.
My greatest misunderstanding before getting it to work was that Wireguard uses the `AllowedIPs` setting both for defining which source IPs to allow, and also for routing traffic back. Means you can't have multiple peers on your machine with the same set of `AllowedIPs` - you need to configure each separately with their exact IP address.
Since WireGuard doesn't do NAT hole punching etc, you'd most likely need to connect from work to your network, and use the `PersistentKeepalive` setting. You can't initiate the connection the other way round.
I've run into both issues, for the first I moved my internal network to a subnet in the 10.0.0.0 range and the second was a DPI firewall at a hotel I stayed at - in the end I have a dual mode setup where if I HAVE to I connect to an OpenVPN endpoint in my network, otherwise it's wireguard all the way.
That’s irritating at best. The whole point of using wireguard, to me, was to move away from openVPN. If I can’t do that then why would I bother hosting a second way to punch through to my network?
Fantastic news. I deploy WireGuard to provide a private network (mesh) between VPS servers. Each VPS instance has each other vps as peer. So no single source of failure. I run PostgreSQL with Patroni and GlusterFS over this mesh with no issues. When I add or destroy a VPS with Ansible all VPS nodes get an updated config and reload. This way I don't rely on a single cloud provider because I do not use their private network service.
I used to do the same thing, but adding one node meant I had to reprovision all other nodes so each had an updated config file written and reloaded. I decided I want something akin to DHCP, which seems to be worked on here: https://github.com/WireGuard/wg-dynamic It's still WIP though.
I use tinc for this. It does the mesh dynamically so I have a few nodes that are fixed and the others will connect directly or indirectly automatically. I deploy it using puppet and there's no need to update all nodes to add a new one. The cryptography and performance is probably not as good as wireguard but more than good enough for my uses. I think there's been consideration to using wireguard as the transport instead of doing everything in userspace.
This problem has be prevented me all the time from rolling out wireguard. But how dows wg-dynamic help which seems just to be a DHCP on wireguard implementation? You still have to sent every existing node and updated configuration because you provisoned a new one.
An overlay network on top of wireguard would be really nice. For example you are running a wireguard network on 169.254.0.0/16. So every peer which is assigned an ip address within this range is by configuration of the network allowed to forward packets to another peer in the 169.254.0.0/16 network. So the only things needed to be implemented would be:
* an internal routing system to forward packets on some way to the destination
* a concept on how peers are found and how they build a secure channel (pre-shared key?)
Edit: A better way would be to have multiple shared secrets for every server. So you could basically assign roles to every server. So if a server has the keys "db" and "middleware" he can communicate with every same in the network for forwarding but the final destination can only be a server which has also one of the keys "db" od "middleware". Maybe such a server would have 2 virtual ips within the subnet, one for it's role for db and for middleware.
While WG is pretty cool, you're starting to describe a simple version of ZeroTier. You can achieve exactly what you say with it, along with multiple networks, chosen/assigned ips, p2p routing, shared keys for authentication to the network, etc. You can put extra filtering or routing rules on top of each of the networks.
Do u maybe know when wireguard would be better than ZeroTier?, been using it for months for p2p(Hamachi like), and for access to the internet like a VPN service. Seems to be most versatile since it works everywhere even behind the deepest nat jungle, and with blazing fast speeds (compared to openvpn haven't tried wireguard yet)
If you have a stable (network) configuration with no roaming machines, and you want as few dependencies as possible, wg sounds perfect. If you want features and don't mind an extra daemon, and don't know what what nats/firewalls are in the way, zerotier rules.
I thought about doing something similar, but with Slack's Nebula or with ZeroTier (v2, which is not released yet). They're specifically designed for this kind of overlay network if I'm not mistaken, taking care of node additions and removals automatically. Nebula with fixed "lighthouses", ZeroTier with a decentralized KV store.
Didn't know about nebula, definitely interesting. I looked into ZeroTier but I believe it has a central control server for connection initiation, and I read some comments about slow connections if I remember correctly.
OP is referring to ZeroTier 2.x which makes it easier to run your own control servers (called root servers in ZT).
Any connection flakiness is probably due to NAT or firewall issues and is going to occur in any P2P network layer since they all use a toolbox of common techniques such as UDP hole punching.
But it only needs to be accessible on the port WireGuard uses for communications, and WireGuard also has a nice property where it acts passively for non-wireguard packets.
So someone on the internet doesn't necessarily know the node is reachable from the internet if they try and scan it for example.
Edit: IIRC only one end of the connection needs a stable endpoint as well. IIRC WireGuard supports mobility (changing IP addresses) for one end of the connection.
I'm considering writing a blog post about it as I documented most steps. Plus having everything in Ansible is more or less a guide / tutorial in itself.
I run a distributed Node.js Express app that has a media folder mounted (fuse) across all node instances. GlusterFS runs with replicated volumes. As GlusterFS is not super fast, I use an Nginx cache in front of all media files. (I should probably use a CDN) PostgreSQL does not run over GlusterFS for the reasons you mentioned. For ease of configuration each node has an HAProxy instance that knows where the master PostgreSQL instance lives. Patroni as well as the Node.js (typescript) app uses Consul for leader election.
It seems like it isn't free, I would appreciate not handing my network over to anyone. Since ZeroTier only runs over udp (which can be problematic) and doesn't route over other peers if p2p isn't possible between nodes I've been thinking about building the same admin and ease of deployment around tinc, which can fall back to tcp443 if necessary.
WireGuard is absolutely fabulous. I route all my traffic from a couple servers at home to a small GCP instance (don’t want IP to be public) and I added my laptop to this WireGuard network (although technically a peer) and I can ssh into it remotely.
I’m serving a 1,000,000+ page views a month through WireGuard and can’t say anything less about it it.
Do you set up nginx or haproxy as a reverse proxy to the wireguard network, or something else? Been wondering if there's an easy way to expose an internal service like that. TCP seems easy, but UDP seems much more problematic.
It does look very nice. It's a shame that it depends on third parties for authentication, and that they have gems like this in their documentation:
> No app-level integration or reconfiguration is required, because security is built into the network itself. If you configure your network to require Tailscale, every one of your internal services will be subject to multi-factor authentication.
Which is simply not true. I've had 2FA for my Cisco AnyConnect VPN for years. That does not mean my applications I access through the VPN are now magically subject to MFA.
Maybe in time this may end up being viable for me, and maybe it already is for other people. For now, I'd rather my VPN didn't depend on Google, Microsoft, Okta, etc.
The idea of a vulnerability in any app I run having access to all my things is quite scary. Status quo is that they at least have to reach the file storing browser cookies before they "become me"; the way Tailscale is talking about their system sounds like fewer barriers.
Network authentication is not the same as application authentication.
If I plug a cable into your LAN, I am not subject to MFA to login to a server on your LAN.
If you have a lock on the network port that requires me to type in a PIN code and stick in a key to unlock, and expose the port, that then results in MFA to connect to your network. Your applications behind your network remain without MFA.
MFA VPN is essentially the same thing as the above, but for remote access to the LAN. Applications should still be properly secured.
I suppose it could be argued that this provides a client-side agent to authenticate the end user as well (mumble mumble 802.1x), and if so, then it's arguable whether or not you need another layer of authentication on the application, or if this qualifies as SSO to authenticate you to everything you have access to in the network (so passwordless login to servers, desktops, webapps, etc)
Another example of a product that looks interesting, but the folks responsible for marketing it make it a pain in the arse.
This looks like it solves a problem I have. Looks like it might be a commercial product (mentions of Okta and "get started for free"), but I can't find out any more information without signing up which I don't want to do if it doesn't support the configuration I want or is more expensive than my budget for such things.
They want early adopters (their friends) to play with their prototype, and they don't want to commit to pricing and long term support before they know what they can build and if it will work and how much it costs.
How does this thing even work? do they host the gateways for you and do the authentication at the start of VPN sessions and generate the wireguard keys for you? so you simply need to connect your networks hosting services and such to their gateways?
I'm doing something similar with a random VPS provider, using and some NAT rules to forward selected ports across the VPN interface. If there's interest, I could write up a more detailed explanation.
If you've followed standard / generic wireguard configuration, then 'client' peers are all able to route to each other via the server on their wireguard-local peer IPs.
If you need any help, let me know at hn@sdan.cc. I'm going to write a couple blog posts documenting how to do this (because it took me a full brain-wrecking week to figure out how to do this properly).
WireGuard for networking and Traefik for loadbalancing is so easy to do (if you do it correctly).
> because it took me a full brain-wrecking week to figure out how to do this properly
I would appreciate a guide as well, really for anything Wireguard adjacent. I tried to get a simple client / server configuration with forwarding set up about 2 months ago and gave up after 5 hours of blood, sweat, and tears. Disclaimer: the server was an OPNsense based router. I probably could have done it between two Linux servers from the terminal. I was using a guide I found online, but it didn't help, which may have been due to using OPNsense, I'm not sure.
OpenVPN may be more complicated in theory, but one really nice thing about it is that there are tools that make setting up a configuration trivial on just about any device that supports it. Not true for Wireguard (yet). I'm sure it will get there eventually.
While waiting for your interesting blog post, I have a few questions if you don't mind :-) :
So your setup is:
* GCP Instance (i.e. VM on the Google infrastructure).
- Traefik running on this instance.
* GCP conntected to Wireguard
=> Is Wireguard run on a router/firewall, or directly
on the DB, HTTP servers? If router, would be
interesting to know which type of router?
* Behind Wireguard: Two servers (DB and HTTP) + Laptop
* You SSH to the two Servers (directly or via the GCP?)
I’ve been nothing but happy with WireGuard. Connecting from my iPhone to my home and it works great, it’s fast and reliable. I’m never waiting to connect. Switching between WiFi, mobile, and sleeping go unnoticed.
In the US for home connections (cable, fiber, DSL) everybody gets an accessible IP address pretty much -- the worst is that some ports are blocked like port 80 or 25. Phones don't get a dedicated IPv4.
In other parts of the World that didn't get as many IPv4 addresses as the US, the standard for home connections is that you DON'T get a public IP address, you get a private IP address behind carrier grade NAT
And that's really NAT, not a firewall, so nothing is "blocked".
You do get public IPv6 addresses from some ISPs, though.
I have a rpi set up with a minutely cron job to update my domain name to point to home. Works pretty well. At the worst you lose connection for a minute but usually the IP address only changes when the home connection fails which can take more than a minute to reset anyway.
Why not? It is pretty simple and very fun! My first project in golang was a program that polled for the machine's IP address and updated a AWS Route53 record.
Its not exactly "write your own" I have a single line in my crontab that just uses curl to post to a url and the remote server takes the IP address it got the request from and sets the dns to that.
Though usually on firmware like openwrt the request going out is tied to a particular interface going up (and down) as it should be, so its somewhat more robust and 'correct' than crontab would be.
Dynamic in theory, but for many people the IP is unchanged for a long time. I remember reading an article that said the average length of time between dynamic IP changes tracked by some company was something like seven months, though I can't find it now.
I have cable with a theoretically dynamic DNS but it's changed once in >4 years.
"This means you can use it to create inbound network tunnels to computers that don't have a public IP, are behind firewalls or get assigned new IPs frequently."
Sure enough, look what appears on HN front page a few hours later...
People's home public IP addresses are not universally reachable/accessible^1 from the internet. It varies.
What does "reachable/accessible" mean. It means that transferring a file would be as easy as person A typing something like
nc -lnp [port] [person A home IP adddress] < file
and person B typing
nc -w1 -vvn [person A home IP address] [port] > file
where port is not one that is blocked, e.g., 80, 25, etc. and is known by both persons.
Regardless of what anyone says in an HN comment, in the real world, people at home are sometimes behind firewalls, or other software that performs NAT, that are running on computers that do not belong to them and are not under their control.
That's why WG has persistent keepalives. No one answered that question.
Come to rural western Ohio, where the only non-dial-up options, in some places, are super-high latency satellite and a local "WISP" who NATs their whole Customer base into what appears to be a /29 (your "public" IP assigned by their CPE lands in 10.0.0.0/8).
NAT and double-NAT are common in WISP networks. Also of course most hotels, Starbucks, schools, conferences, airplanes, albeit those are not ISP services. And cellular carriers often NAT.
Almost every ISP will have a firewall of some kind, but in the US this is usually just blocking 25 incoming, sometimes 80 (fios), maybe a few other ports.
I have run services on port 443 on Optimum and FiOS for years.
IP addresses don’t change frequently. Usually what happens is there will be some maintenance and you’ll end up with a new IP because you lost the lease in the interim. If you keep your equipment on though you can have the same reachable IP address for years.
I use a dynamic DNS service so this is rarely a big deal.
Not sure why this is so hard for you to grasp. You keep arguing, for what reason?
"I have run services on port 443 on Optimum and FIOS for years."
What is Optimum, FIOS.
WG does not work over TCP.
Try running a UDP-only DNS server from home on some random port. If you know the port can you reach it via UDP from the internet.
A TCP service listening on port 443 on an ISP customer's IP address in the US might be reachable from the internet. However, this topic is neither TCP nor port 443 nor is it restricted to just the US.
> Try running a UDP-only DNS server from home on some random port.
No reason to run DNS.
However, I run openvpn udp between three houses (fios, Comcast, cablevision) for nearly 15 years. It’s pretty common, works fine.
Again in the US... cable, fiber and dsl internet service comes with a public mostly unfiltered IPv4 address, the address is dynamic but in practice it is extremely stable.
End of story.
No idea why you’re acting like such an imbecilic tool in this thread. The whole time I have mentioned that this is the case for major US “landline” ISPs. Yes there are plenty of counterexamples, not sure what point you’re trying to prove.
Yes, pretty much since most ISPs do not block UDP port 53.
I have no reason to run DNS on a home internet connection. What would a sane use case be? They don’t block it because it would be stupid to use it anyway.
Ports that are typically blocked include 67, 139, 161, 520, 547, etc.. ie dhcp, rip, smb, snmp... none of them are any great loss to those that want to run a vpn.
Running a VPN or ssh service is another story and it works fine both TCP and UDP.
Does anyone know anything about Wireguard-p2p?
It's a tool for automatic management of endpoints and NAT-traversal for wireguard. It was announced on FOSDEM 2018[0]. Main repo[1] is stale, unfortunately.
Some tool that would augment WG with more features a-la Tinc would be awesome.
WireGuard is cool and we really like it at our company (a bunch of infosec consultants). The management of it for an even small number (20) of users is a no-go. OpenVPN is ultra reliable and provides legit 2FA options when set up well. I look forward to legit management tools and improvements. For personal use it has been great. Much simpler than OpenVPN for a few (3) users.
The way you're managing WireGuard today is like directly configuring KAME IPSEC. The Linux WireGuard implementation is low-level and, from a systems perspective, unopinionated, which is as it should be.
Getting a secure transport integrated safely into the kernel shouldn't be rocket surgery, but it is. That part is done. Getting IdP-managed WireGuard is not rocket surgery, and lots of teams will presumably do it. Those teams, by the way, stand to make a lot more money than Jason will off WireGuard, which is a very good reason to donate.
Nobody who can reasonably avoid it should be using OpenVPN anymore. I get that it's burrowed far into some organizations and am not OpenVPN-shaming anyone. But WireGuard is leagues beyond OpenVPN in terms of nuts-and-bolts protocol and implementation security.
I'm a big fan of Wireguard, and am using it in a few places, but OpenVPN still has its place - namely if you need a VPN tunnel from behind a firewall that only allows outgoing connections to small number of TCP ports, and no UDP ports.
You're not wrong. OpenVPN can be useful in that case, but in general you shouldn't use TCP as the underlying protocol for other TCP traffic, if you can avoid it. The better solution in this case would be to open a UDP port in the firewall.
I would dearly love to see it make its way into pfsense, at which point I could reasonably execute on that vision. Right now I'm using both OpenVPN and Wireguard, and I'd rather not be.
I got the feeling that it's presently aimed more as a replacement for IPSEC site-to-site VPN, which is annoying as hell to configure considering the number of implementations and likelihood that one messed up setting will cause an inscrutable problem. Cipher suite incompatibility, subnet export and routing issues, and there's always the delightful fact that it never seems completely clear that you've got a tunnel up and running. I welcome a clear alternative.
Those will be widespread eventually, it's still relatively new, just hitting Linux mainstream kernel dev, so probably 2 or 3 years before tried and proven management tools come out.
WireGuard® is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it is now cross-platform (Windows, macOS, BSD, iOS, Android) and widely deployable.
Right now, it is not part of the Linux kernel. It is just some random external software that you have you download and compile yourself against the source headers of the kernel you're currently running.
It got merged into the net-next tree, which meant it has been approved by the maintainer of the Linux kernel net branch to be included into the kernel. Linus has now pulled it from net-next into his own tree, which means it'll be included in the next release of the Linux kernel.
As far as that means as an end user, it means that you no longer need to recompile your wireguard module every time there's a kernel update, as now it will be handled by your distro.
That said, given that Wireguard is packaged nicely already for most distros, the end effect for you is really pretty little, as you're probably unaware of all of this complexity that's going on right now, as it mostly just works.
> As far as that means as an end user, it means that you no longer need to recompile your wireguard module every time there's a kernel update, as now it will be handled by your distro.
That's not the important point.
The point being, when merged as part of the kernel officially, you know it will get more support and eyes for stability and development power as the kernel wouldn't want to ship anything that's at some unstable state.
So you can expect long term usage and maybe RedHat might pick it up as its official VPN solution instead of libreswan some day.
>you know it will get more support and eyes for stability and development power as the kernel wouldn't want to ship anything that's at some unstable state.
This is a rather idealistic view on kernel development.
But it is true that when wireguard is “ready” this could very well result in a bit more support as larger orgs will be more willing to start using wireguard.
It will now end up in all Linux distros by default. Instead of having to chase it down and apply a bunch of patches it’s now just a single config option away.
Not all linux kernel modules are in the main sources. Many projects begin outside the main tree and are pulled in later after they have proven themselves and have matured, responded to criticism, etc.
Right now Wireguard is using DKMS which is like a external Kernel module which needs to be rebuild on every Kernel update. When WG is already inside the Kernel no dynamic created DKMS are needed anymore.
A major difference, besides WireGuard's simplicity, is that IPSec is a layer 4 protocol (ESP packets instead of TCP/UDP packets) whereas WireGuard is a layer 5 protocol (runs over UDP), so switches don't choke on it, and so a WireGuard peer doesn't need a public-routable IP address, but can be behind NAT.
"fine" with NAT is a bit of an overstatement, I don't think anyone who has seriously interacted with IPSEC would call it anything but a gigantic pain in the ass
I'm not "seriously" interacted, but I have VPN server and I'm using it on all devices in my hope (laptop, PC, phone) which are behind WiFi NAT. They work just fine. I'm using strongswan and IKEv2 on server.
More likely is that both ends are using IPSec NAT-T (https://tools.ietf.org/html/rfc3947), which has been widely supported for some time. NAT-T encapsulates IP packets inside UDP, with the IKE daemons (usually) as the UDP endpoints.
WireGuard operates at layer 3. The first sentence from the white paper by Jason A.: “ WireGuard is a secure network tunnel, operating at layer 3...”. [1]
Regardless of the layer, in a few words WireGuard is a simple encrypted tunnel over UDP. Since it’s UDP - there’s no guarantee all packets will be delivered, BUT - what WireGuard places emphasis on is all packets delivered from the WireGuard interface will be authenticated and encrypted. Similarity if packets are received from a particular peer, replies to that IP address will be guaranteed to go to that same peer.
The best feature of all imho is OpenSSH inspired authentication - makes configuring server/peers really straightforward.
The tunnel does not have to encapsulate messages at the same layer as the tunnel itself. Consider this thought experiment: if you send Ethernet frames over WebSockets, what layer is the protocol?
My understanding is the Wireguard messages are IP (L3) but the protocol messages itself are UDP (L4) and it seems reasonable to describe Wireguard as a session layer over UDP given how much state and connection information it maintains.
I see what you mean. Specifically in the context of VPNs I’ve always interpreted the layer in terms of the payload that’s being encapsulated - which as far as I understand is IP (L3) packets in Wireguard’s case.
Maybe due to my own ignorance I misunderstood the meaning of derefr’s comment. Apologies if I sounded rude!
No worries, you're fine, just trying to clear up the confusion. I've heard both terms used interchangeably depending on context. _Usually_ as an administrator you care about what's in the tunnel, but _usually_ as a designer you're worried about how the tunnel itself is communicated, so, yeah, confusing :)
It never ceases to amaze me how stubbornly educators have clung to the OSI model. It describes a non-Internet protocol stack which was designed in the 1970s, and which was never fully implemented. Attempting to use its layers as an ontology for Internet protocols is doomed to failure, as some of its layers (especially Layer 6) describe components which have no direct equivalent on the Internet.
Layer 6 exists, it’s just that most layer 7 protocols “fix” their layer 6 protocol. E.g., JSON/RPC requires JSON; SOAP requires XML; etc.
But Layer 6 is where the difference lies between ASN.1’s representational encodings—DER, BER, XER, etc. You can switch out this “presentation layer” encoding without either your application layer caring (it just sees an ASN.1 codec library) or your transport layer caring (it’s just transporting an opaque octet-stream payload document.)
One might also describe Avro, Parquet, etc. as “presentation formats”—they all have canonical input ADTs, but multiple possible wire encodings depending on the schema supplied at encode time. But all such schemas decode back to the same input ADT.
OK? The Internet does not use OSI, but it sure was helpful just now as an educational tool for describing that "what layer a VPN operates on" can be confusing. Even if you don't literally use OSI layers, knowing that UDP builds on top of TCP and having a common vernacular to express that is pretty useful. Given that the entire thread was already using specific OSI layers (which have clear mappings to things the Internet does do), starting by saying "the OSI model is not what the Internet actually does" does not seem to be the most productive avenue towards fostering understanding :)
I dont know why you're being downvoted. It is a vpn protocol, just like IPSec, with the main difference being its much simpler, and hence "sucks" less.
Super cool. WG is a such a great tunnel tool. They've told me not to use in production but I've been ignoring that advice for months. My first test was using in as a replacement everywhere I still has stunnel. Then right after it was proved I started using this hammer for everything.
AND! This part is critical: all of my interactions with the team and the community around it have been positive.
This is great news, and I'm looking forward to giving it a try once it's released as part of the kernel.
I've been using tinc[1] for several years now, and it's been very simple to configure and use. Similarly to WG, it can tunnel over UDP, but also over TCP, supports router or switch modes, NAT traversal, etc. It's a great project, but not very popular and I'm concerned about its maintenance and security issues moving forward.
To someone who's used both projects: can WG today be a drop-in replacement for tinc?
As far as I understand, the killer feature of Tinc is automatic mesh routing. You can add a node to one instance and the information spreads through the network, wireguard doesn't do that.
Also, I heard maintainers were contemplating replacing the protocol with Wireguard.
IPsec also supports this - give certs signed by a mutually tusted CA to all nodes and they can all communicate host-to-host in a full mesh without needing to reconfigure when adding a host etc.
What they mean is that with tinc, you can connect from node A to node Z without A and Z being directly connected. Tinc discovers who is connected to whom and will route through nodes to reach one another dynamically in user space.
IPSec by itself can not do this without adding very complex route statements on each node and enabling packet forwarding. Tinc operates in user space and does not require kernel packet forwarding or any destination node specific route statements.
Can you please elaborate? As far as I see it, IPsec is encrypting traffic. IKE is for setup of security associations. What part of IPsec would do routing, and in this case: potentially multi-hop mesh routing?
I use WireGuard on OpenBSD and Linux and it is just simply beautiful.
THANK YOU Jason for writing it and to everyone else who has contributed code, testing, money, whatever.
I believe WireGuard will become the most widely used VPN above IPsec and OpenVPN. There will still be use cases for them (especially IPsec) but both will lose marketshare dramatically.
WireGuard is nice but needs 2FA support. Until then it can’t be used in various corporate road warrior scenarios.
Also until Cisco, Juniper, etc add WireGuard support and enough devices are deployed with it, IPsec will remain the corporate tool of choice when connecting between different organisations. Within the same org, where you have greater control of the equipment used, WireGuard is a bit more feasible.
What you're describing (authentication/2FA) should be handled by a client application. VPN client software should handle authentication/authorization with the corporate VPN server. Once it's authenticated, it can exchange/generate the public-private keys used for the WireGuard tunnel. The VPN client then installs those keys and starts the tunnel. After that, it's up to the client and server VPN software to handle session timeouts, reconnections, host machine security policies, etc etc. None of that is the job of WireGuard itself.
That’s still just one factor on the tunnel itself, which is the problem. If the keypair is discovered somehow, attackers could connect to your network without 2FA. Or am I missing something?
So what software can I use now to make 2FA work with WireGuard that’s simple to use - as simple as OpenVPN (cert+user/pass is trivial in OpenVPN and supported in their clients).
This is awesome news. I’ve been using my self written access server deployed as a docker container at my home for ages now with no problems at all. Wg is a pleasure to use and their apps for iOS and desktop are great. The QR code feature in the mobile app is really good.
I can’t wait for better adoption amongst businesses for corporate VPNs.
Glad to see it finally officially accepted. I've been using it on all my devices for over a year now and it's been rock solid. The ease of setup and initial connection speed alone blow any of the alternatives (that I'm aware of, at least) out of the water. Long may it continue!
The only place where it falls shorts is that it doesn't go through as easily as SSL/IPSec on restrictive networks like corporate firewalls, but maybe that will go away when it becomes more common (and hopefully adopted in enterprises).
I've honestly not had a lot of issues with that up until now. Real world it doesn't seem to be blocked by a whole lot of things, except where you only have port 80 and 443 anyway. I've actually seen it work in a lot of places I wouldn't have expected it to, like hotel wifi.
Actually there are workarounds to get Wireguard running over TCP and port 80/443 described here (like udp tunnel). I also wanted to check them out for very restrictive networks in the near future:
Basically nothing for wireguard itself. I've run it on some seriously underpowered hardware and it seems to have basically no performance impact to speak of. I probably have it set up on around 30 machines presently and have used it in production environments.
Just yesterday I was looking at tinc [1] and wireguard was mentioned briefly. I'd like a way to access my home computers via ssh to keep them updated via ansible, even if they are on different networks (parents' laptops, my laptop, my raspberry servers, etc).
Does anyone with more knowledge care to comment on security issues with tinc vs wireguard?
Too bad that you need to use an external droplet for discovering the hosts with this one :(
I cannot comment on tinc, but I use WireGuard to do the same thing as you, and it works brilliantly. It was “easy” to set up and use.
I wrote up what I did for my Raspberry PI server that I have at home [0].
The only other component that may be necessary is Dynamic DNS if you have a dynamic home IP address, or at the very least a way to find out your home IP at any time.
I have been using wireguard via telegram and discord. Bot generates a config, whip it up and send generated QR code/file/instructions. It changes the DNS to the proxy pihole so whenever I connect to vpn, most ads stop bothering me.
It's been great because I can easily give access to others via the bot too. They only need to scan the QR code or download the file, import it in the official app and it works. :D
Is the Windows client offering better now? I'm still using the old alternative Tunsafe client on Windows because it is more stable than the official client on my laptop (got several bugs with sleep/resume/hibernation/long lived session).
Well... I just tried to install the latest official Windows client and got an error about Wintun missing when activating a tunnel :/
I thought the Wintun driver was bundled with the WireGuard installation but if you need to install it separately I believe you can do it from https://www.wintun.net/
Hope it helps. The Windows client is very stable now.
So,curious here: I'v been reading about how the focus these days is to move networking code to userspace because you can squeeze out more PPS performance,does the fact that WC makes use of kernel code heavily give it a performance disadvantage?
Most of the userspace high-performance networking stuff is still pretty exotic. It requires plenty of tuning, specific network hardware, and sometimes extreme conditions, to be viable. DPDK does not work on the wireless connection I'm using to post this reply, for example (nor any wireless connection for that matter).
Meanwhile, if you're not doing that: Wireguard can avoid lots of syscall and copying overhead plus some magic CPU register overhead by being in the kernel. Hence this almost certainly makes wg faster on the net because it can't pick and choose what environments it runs in.
You could always use a userspace implementation of WireGuard like https://blog.cloudflare.com/boringtun-userspace-wireguard-ru... . I imagine the advantage of the kernel module is good performance for normal users who are not trying to wring every last bit of performance out of their network setup.
If all networking happens inside kernel, it'll be as fast as possible. People write userspace code because they don't want to put their application into kernel for obvious reasons. And with userspace code it makes sense to move everything into userspace, including network drivers, etc. But it's not a standard configuration and compromises on security.
A polling/batching implementation of WireGuard would be faster than the Linux kernel implementation although it would be much less convenient to use. If WireGuard spends, say, 90% of its time in ChaCha20-Poly1305 (which is already highly optimized) then there's only room for less than 10% speedup.
it could be faster with a hardware chacha20 implementation. if wireguard gets really popular, we might see that eventually. I'd wager a guess that we would get hardware wireguard first though, with fast path acceleration, similar to hardware TLS.
Modern CPUs are pretty close to being ASICs for ARX ciphers like ChaCha. Add, rotate, and XOR all have dedicated die area. Bernstein designed it that way.
Are there any hardware ASIC implementations of ChaCha or are they basically unnecessary?
You're only half right - projects attempting to achieve very high speed networking (packets per second) go to great lengths to remove the traditional syscall per packet that normal linux networking involves.
One approach to this is to move everything into userspace and take the kernel out of it completely. Another approach used by some projects is to put everything into the kernel and take userspace out of it completely. Either of these approaches remove syscalls.
The kernel isn't an inherently slower place (in some cases it can be faster as you have more control), it is having your network stack split across the kernel/userspace boundary that is slow.
You're correct. I don't know why you're downvoted. Anything you can do to get performance with kernel bypass techniques can be done inside the kernel as well.
¯\_(ツ)_/¯ It’s alright. You sometimes get downvoted by the early two people who are offended that I’d dare comment without knowing what PPS is (or something equally offensive).
It's possible to write a driver that doesn't use polling - for example https://arxiv.org/pdf/1901.10664.pdf which discusses using vfio though doing so is apparently much harder than polling alone due to the complexity of the vfio interface and that most users care more about maximizing PPS performance at peak vs saving CPU cycles when less busy. Presumably one other option would be to try and tune the CPU to run slower when less demand is expected, and only run at faster peak performance when absolutely required. Also, it sounds like you might want to look at pinning cores to workloads, such that only one of your CPU cores is polling while the rest act as dynamic worker cores and could do other activities. Note that I'm largely speaking theoretically, for my use cases (mostly at home), the incompatibility of user space networking stacks often gets in the way.
> It's possible to write a driver that doesn't use polling
Yup, definitely possible. It just doesn't give the PPS numbers as polling does. The project you linked to is really cool, but it is an academic project. It's not trying to compete with DPDK or anything.
IO is one of those things in computer science that forces us to make trade ofs. What is more important to you? Raw throughput? Latency? Overall resource usage? You can't optimize all three.
> it sounds like you might want to look at pinning cores to workloads, such that only one of your CPU cores is polling
Correct again. It may take more than one cpu (DPDK is commercial software running on 88+ cpu systems) but cpu pinning is definitely the recommended way to go. In the spirit of spending CPU to buy IO speed, dedicating physical cores to the task always gives you the best bang for your buck.
Since a couple of years I've been running iked [0] on my VPSed OpenBSD. It took me around 5 minutes to setup and it "just works" since then with my iPhone and MacOS clients out of the box, not requiring any additional software.
But since WG is getting so high praise here, I'm now interested what are WG advantages and what does WG have to justify the effort to move away from iked and install/setup the client software everywhere?
I'm certainly going to find out and test it myself, but would really appreciate just a quick answer/explanation
For me it's just easier to get my head around having a new network interface presented rather than this pile of security associations and transform configurations. I can just re-use my firewalling and routing knowledge and do not have to put my mind into IPsec mode to manage this. That aside, I think it's still quite a lot easier to use IPsec tooling when you want something that plays along with certificate based multi-level trust models.
Wireguard is really, really awesome. I've been using it for a bit now and it almost completely Just Works™. I've only had two issues, one of which is known and the other of which I think is probably my fault somehow.
The first is that for some reason I sometimes need to ping machine B from A in order to get to C via B (in my case B sits in a VPS, while A is a laptop and C is a desktop).
The other is that I would love to be able to connect directly over the LAN from A to C and vice versa, only going via B when A is mobile. I'm pretty sure that I could fix this with more IPv6 addresses and routing tables, but so far no joy.
I just started looking into WireGuard and was disappointed to find out that pfSense has no support for it. I don’t like messing around with packages outside of the pfSense repo, even if it’s kinda supported in FreeBSD.
Anyone aware of a VPN provider that offers WireGuard and supports more than 5 simultaneous connections? I've been using Mullvad but the 5 connections limit is starting to feel really restrictive.
I set up a home router that I can connect to through Wireguard from all my devices, and it forwards all traffic to Mullvad. Bonus: I use PiHole on the same instance so all my devices get transparent ad- and tracker blocking
Very glad to see WireGuard getting more adoption. I've been using it while mobile and traveling and it's been absolutely rock solid.
OpenWrt router back at home, multiple Android devices and Fedora machines connecting back that just work seamlessly between different networks. It's been such a treat to use and watch and help it mature.
Just need more popular VPN providers to start supporting it -- NordVPN and PIA have provided "support" for it, and Nord allows using it as "NordLynx" on their Linux app.
I found the speeds to be lacking quite a bit and it was never completely reliable with both the WireGuard app and the official Android app, which also doesn't support split tunneling or allowing specific apps to bypass the interface. I will revisit when my subscription with current provider expires.
Using WireGuard to establish a mesh network seems good to start with but it does not scale well (even with the help of subspace web UI). Nebula (from Slack) seems to be a better option which is simple, secure and scales well so far, docs are not that well at this stage but usable.
My main use case of WireGuard is to secure network traffic on Laptop/Workstations, replacing old-school complicated IPsec (strongSwan) and OpenVPN, can't be happier with its simplicity, user experience (seamless switching networks like strongSwan client for Android, per network on-demand, etc) and performance, battery life on mobile devices, etc. Anyway, non of the traditional VPN solutions (including WireGuard) work inside the Chinese GFW when travelling to China Mainland (won't go there until the 2019-nCoV is under control or a vaccine is available). So I am exploring V2ray (TLS + WebSocket + Web) and Trojan at this stage (working ones to my knowledge).
Gravitational folks even implemented a WireGuard based overlay network plugin for k8s, super excited to replace flannel with wormhole (I have to admit it is a bad name) in use cases where encryption is required for overlay networking, which flannel does not offer.
Many thanks to the WireGuard development team for the good work! Jason and many others, wow, I see the name of a long-time-no-see frined Herbert Xu (crypto subsystem maintainer).
Forgot to mention a potential problem with WireGuard, server keeps the list of clients' virtual IPs (AllowedIPs used for routing/ACLs), not ideal for VPN service providers in terms of privacy.
It's not a problem for overlay network (e.g. Nebula) though, as it is considered a `requirement`.
Apologies if I've missed it, but which kernel version will be first to ship with Wireguard? Looks like 5.5-rc7 is already out, so will Wireguard be included in 5.6?
Unless underlying protocols (OSI layer) OR government policies don't stop WG from working, there should be no other variable to technically stop WG from working.
As far as I understand it, that's not the general rule.
This is hardly a authoritative citation, but it cites a number of authority and comports with my understanding as someone whose name ends in `s`:
"Nearly all authorities agree that if you want to make a possessive out of a singular noun like Kansas that ends in an s, you need to add ’s at the end. Just call it “Ross’s Rule.”"
The Chicago Manual of Style which is pretty much the authority in the USA says you do apostrophe-s for all possessives even if it ends in an “s”. So “Ross’s” if it is a singular Ross.
But if you’re describing a family possession, it would be Rosses’ as is possessed by more than one Ross.
Now that it’s merged into Linus’s tree, any word on it getting an official release and the “this isn’t production ready, so no CVEs” disclaimer going away?
EDIT:
Further back in the thread, Donenfeld says “Please note that until Linux 5.6 is released, this snapshot is a snapshot rather than a secure final release.”, so perhaps real soon now?
https://lists.zx2c4.com/pipermail/wireguard/2020-January/004...
This is definitely big news!