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.
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.
It's a lot more if you do it all manually, however for most "common" use cases, one should probably go with automatically generated config files.
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.
I wonder how WireGuard compares to IPsec with regards to the mobile battery. AFAIK IPsec implemented in kernel while WireGuard uses user-space implementation on mobile devices, at least for now.
The code has been merged into the kernel as of 5.4(?) I believe, but we won't see that on mobile for quite awhile. I'm guessing IPSec will still have a lead on mobile for awhile for that reason, not that it has sort of majority on there anyway.
You're not misremembering -- Linux has releases every 6-7 weeks. WireGuard was merged into 5.6-rc1 a little over a month ago and the story was posted to HN from memory.
In some cases, countries. In the country I'm thinking of (name omitted on purpose), you have an effective choice of two ISPs, both government-controlled.
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.
huh .. OpenVPN is UDP by default but you can force it to TCP (we had to do that at one University site that would only open limited tcp ports for us).
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.
Or much slower on systems with AES-NI, but relatively slow CPU. Like are used in some hi-end SOHO routers.
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).
Good point. AES hardware acceleration makes a massive difference. It's why ZeroTier 2.x will use AES. Tiny boxes that lack HW acceleration are generally not used in cases where they're pushing enough bandwidth to matter anyway.
i did test it. in my setup we couldn't get IPsec to not drop a lotmof packages, so the benefits of aes-ni was lost in retries. switching that IPsec setup to chacha20-poly1305 actually made most of the drops go away.
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.
Makes a good argument for having a mobile phone on the mainline kernel, rather than on some ancient kernel with a thousand hacks layered on top. Something like Pinephone should get access to this more quickly than a standard Android device.
In my experience the problem with roaming mode is it blocks the login page for wireless networks. IE: in a coffee shop. Maybe that's been fixed recently, but it was a giant PITA in the past.
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.
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.
If you're subject to state level actors attacking you, a VPS is probably the least of your worries. If you're just trying to make sure some kiddiot in a coffee shop isn't doing mass collections, a VPS is perfectly secure.
That's kind of a tautology. If you assume the system is insecure, then yes its going to be insecure with that assumption. This is going to be true of any VPN system, so i think its an unfair criticism to level against this particular VPN setup.
If you want to be secure against local adversaries, use TOR.
this is my favorite extremely annoying but massively useful "acktually..."
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?!
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?
The bad actors who want to steal your passwords and credit-card data, and the state actors who want to spy on Persons of Interest, don't know each-other or talk to one-another. A VPS provider being compromised by a series of private individuals doesn't imply that your VPN running on such a service is going to be sneakily MITMed, because there's no obvious profit motive in doing so (unless you're a very publicly super-rich person who is also very publicly using the service, and it's very obvious how to blackmail you if you could just get data exfiltration via that service. Like Jeff Bezos with WhatsApp.)
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.
> Does the VPS have unencrypted access to the VPN?
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 additi...
Thanks for the elaborate answer on my, in hindsight, not very clear question.
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.
>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.
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.
I honestly think the algo ansible scripts just make it more confusing. I agree with you, setup isn't that hard, and you learn it better setting it up without ansible scripts.
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.
I was in a similar situation. Port forwarding worked perfectly. In my case the server I was trying to access was behind an ISP (Comcast) managed NAT so I had to go through them to open the port. Much to my surprise they were extremely helpful and understanding of the request.
Yeah, I noticed that it failed on Hetzner when I tried it about a year ago. What I did instead was use boringtun from Cloudflare. Did not open any ticket though. I might want to try again and see if it works.
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 think the idea is that you're supposed to build a system to manage WireGuard using that sort of information. I.e. WireGuard provides the basic primitives and second- or third-party tooling uses them.
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.
Yep, that's what I'm asking for... right now wireguard can only look at configuration text files AFAIK. If it had a way to invoke a command/script to lookup a key/ip, any number of external management systems could be created!
This is what I do. I have a small dynamo table and a Python script I run from cron. I grab all updates since the last run and apply all changes to the running service. I have the config option set to write out the config on service stop, so I don't lose anything on a restart and don't have to replay everything. I have lots of room for improvement but it's a quick hack that works for my needs. (Not sharing yet because it doesn't fully CRUD right now.)
actually wireguard doesn't look at text files at all, it only has a netlink interface so you can configure it using the `ip` command. The current tools read the text files and set up the network interface.
If you look at their tutorial video, you can see what's going on. The tutorial has a lot of commands like
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........
If you look at the wg-quick script, it basically reads an /etc/wireguard/<adapter>.conf and runs the same commands based on your settings.
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.
Algo (mentioned above) will generate a bunch of profiles for you (including QR codes to configure mobile devices without needing to type awkward strings), which works pretty well for me - at least with a family you won't need to add or revoke identities very often I'd hope...
I'm using Algo right now and it's perfect if I plan to maintain the same server consistently. The problem is that we're constantly traveling around and latency suffers when trying to connect to a box in DO's NYC3 from Vietnam.
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 completely agree that it should never be part of Wireguard itself. Mostly looking forward to the project and tooling ecosystem that develops around it.
Tailscale looks like it's creating a mesh network - he's not asking for end-users to have VPN connections between each other (what Tailscale is doing).
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.
We get this question about ZeroTier from time to time and the answer is the same: set rules (or ACLs in Tailscale) so as to allow only traffic to/from what you want users to communicate with.
Sure - you can block access but the fundamental problem you're appearing to target isn't what he's after. Heck to even get the user-auth he's asking for you have to use tailscale + some third party app whether that's okta or azure or google. I'm not saying he can't sort-of accomplish what he's trying to do but it very much feels like you've got a hammer and think his screw looks like a nail.
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.
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.
Tailscale looks awesome but I would love a tier between “free single user with gmail” and “$10/user/month + GSuite/etc” (GSuite itself is $5/user/month I think?). Something like 1Password’s family plan, with the ability to use gmail accounts.
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.
Wow! I'm super happy I gave this a try. I've been trying to put together an elegant solution to this problem for my personal infrastructure for over a year now and the furthest I ever got was an OpenVPN server on DigitalOcean and an EasyRSA folder full of certificates. I was living in UK university halls at the time, so my main use-case was being able to access my computers located in my UK uni dorm while visiting home in the US and accessing my US machines while at university in the UK.
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!
This looks pretty interesting. Can I setup a sink inside my AWS vpc ? So that everyone can access my RDS database?
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.
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.
This is good to hear. There is a lot of trendy junk that people seem to want in the linux kernel. I've been waiting for WireGuard to prove itself before I give it a shot.
For anyone wanting to set up WireGuard with the Pi-hole DNS blocker: I would advise https://github.com/racbart/wireguard-pihole. Just a simple shell script. No Docker or Kubernetes required. I installed it on the cheapest DigitalOcean VPS, and it has been running without issues for over a month now. (About 6 phones of me and my friends, and a few desktops are using it.)
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.
I am actually not sure. I know raspbian has modifications in it that take care of board specific issues in it, such as high power consumption/heat from some issue related to USB PD and/or power states. I am not too familiar with the inner workings of distros and how hardware-specific fixes are propagated, but I like the idea of sticking with officially supported OS/hardware combos for "set and forget" boxes.
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.
Interesting, can you cure my ignorance on why they don't claim to include 5.5.13 kernel in the main download page? I'm not super familiar with how distros are packaged up for consumers
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?
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
That's what I've been doing, but I would like more official support for something as critical as VPN. I don't forward many ports across my NAT, so I really rely on the VPN to be rock solid. I am considering getting a second raspberry pi and running wireguard on two ports on two pis for redundancy (the ability to fix stuff after a bad update or me breaking something).
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.)
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.
Well, strictly you could use the userspace implementations on Linux (which I looked at because I wanted to try running it in a Docker container, which does work with openconnect).
You could, and that's how the Android version works (at least, until Android has wireguard.ko built-in -- the WireGuard app supports both versions). But if you're using it on Linux you're almost certainly using the kernel module.
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.
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.
Yeah, the documentation on the webpage isn't great - there isn't actually an example that you can follow step by step to get a usable tunnel. That's unfortunate, because it isn't actually that hard.
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.
Before connecting each client needs to be set up with (1) its own private key and (2) the server's public key. The server also needs to have each client's public key. Once you have securely shared this information out-of-band, there cannot be a man-in-the-middle attack because both sides know the expected public key of the other side, and can prove ownership of their own public key.
And no, out of the box there's no equivalent to "trust any cert issued by this CA and lookup the username in ldap based off of the cn". Enterprisey auth is left as an exercise for the reader.
I think you're getting downvoted because the post mentions the "codebase undergoing a quick security audit", which... I grant isn't the most in-depth and reassuring thing they could say, but certainly beats the previous "nobody has audited this, don't use it" (paraphrasing, but that's loosely what their front page used to say).
Do I understand correctly? You use WireGuard to set up your own VPN servers? Doing this is a lot more expensive than buying a VPN subscription, but it can be more secure if you know what you're doing, right?
A VPN is one use of a Wireguard tunnel. Wireguard establishes a stateless encrypted connection between two peers, and exposes it to the user as a network interface. Endpoints can roam as with mosh
'Buying a VPN subscription' is just one use-case. Usually, those VPN services are intended to be used to circumvent geo restrictions.
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.
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/)
An an ex-OpenVPN user, I consider the ability of the server to push arbitrary scripts to the client an antifeature and a security problem that needs to be carefully mitigated every time.
212 comments
[ 0.15 ms ] story [ 250 ms ] threadGreat 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
https://github.com/pivpn/pivpn
There are a bunch linked from the links section at the bottom.
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.
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
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 additi...
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?
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!
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.
https://www.wireguard.com/quickstart/
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.
FWIW the userspace implementations are quite good, and still out performs IPSec.
But the 'not invented here' syndrome is very real.
https://github.com/cloudflare/boringtun
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…
https://en.wikipedia.org/wiki/Linux_kernel_version_history
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.
https://www.kernel.org/category/releases.html
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.
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.
Much better documentation is here: https://github.com/pirate/wireguard-docs
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?
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.
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/)