For anyone wanting to try it, WireGuard with Algo VPN [1] to set it up on a server is a great combination. I found it quite easy to setup and use.
Algo has built-in support for various cloud providers, where, when you run it from, day, your desktop, it can setup the VPN server for you based on answers to some questions (with sensible defaults) and some information on connecting to the provider (like an API key, for example). You also get QR code images that you can use to install a VPN profile on your phone.
You can also run Algo from within a server and have it setup the VPN for you.
I id have some problems with algo behind a NAT. Though my usecase is a bit different, more of a road warrior, as I wanted to be able to access a server in one property (behind NAT) from my home PC (also NAT).
I suppose I just need port forwarding.
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.
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.
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.
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?
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?!
> 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 addition to the regular type of attacks that all hosts on the internet are subject to.
Whereas with a VPS provider, I imagine that they are primarily monitoring for the regular type of attacks mentioned before. VPS providers will notice, and shutdown VPSes that have been compromised if those compromised machines are participating in DDoS attacks on other hosts, sending spam, or burning too many CPU cycles as a result of cryptocurrency mining malware having infected them. But unless notified by one of their customer about the specific type of attack where data is being exfiltrated or tampered with on an infected VPS itself, most VPS providers would be unlikely to notice such a type of attack I think, and furthermore I think this is natural to expect. After all, when you rent a VPS, you are specifically paying the company for the privilege of you being in charge of what that VPS is doing, and for them to largely stay out of and away from your VPS itself, no? At least, that's the way that I think about it. As long as the VPSes are not consuming excessive amounts of resources and not being disruptive or malicious towards external hosts, I think both the VPS companies and their customers expect the VPS company to not interfere with what the VPS itself is doing, and to not be surveilling the processes, disk and memory of the VPSes. It's a virtual private server after all, right?
So that's another point for the argument I think you are trying to make.
But I don't see VPN service providers as being much safer as a whole. I think it is highly probable that among all of the companies that provide VPN services, it is likely that a significant portion of them are straight up malicious. By that I mean, they say they don't look at your traffic and they say they don't keep logs. But for all we know, and given the fact that many forms of cyber crime is profitable enough that criminals are engaging in it, I think it is reasonable to suspect that quite a few of the providers are mining your data or worse.
This brings me back to the first part of your comment, which has me confused about what you mean.
> Does the VPS have unencrypted access to the VPN?
Confused because yes, this is how any VPN works. You get an encrypted link between your device and the other end of the VPN connection. The VPN connection extends only to the VPN server/gateway that you connected to in the first place, no matter if that is some VPN server you are running on a VPS yourself, or if you are paying a VPN service provider for it.
The extent to which your data is encrypted or not all the way to the final destination will be entirely dependent on what kinds of traffic your device itself is sending in the first place.
If your device is tunneling unencrypted traffic inside of the VPN connection, then unencrypted traffic will be what comes out at the other end where the VPN tunnel is terminated. There is no way around that. The only thing you can do, is to ensure that your device does not try to send that kind of data through the VPN in the first place, if you are concerned about said traffic being visible at the other end of the VPN tunnel.
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 wish people would stop automatically recommending Algo, for instance it doesn't support Arch. It's the best if your platform is supported. Otherwise, it's easier to just manually set up everything.
Three of the top 20 list on distrowatch are Arch or Arch derivatives, including the number 2 spot. Its wiki is widely recommended as well for users of any distro.
"Niche" is a bad way to describe Arch.
It's probably more likely that a person interested in setting up WireGuard and their own VPN are running Arch or a derivative than any other distro.
I love Arch's wiki and the userbase's enthusiasm. But how in the world do you think Arch is the most probable distro base for a wg user? Using your distrowatch reference, 4 of the top 5 are Debian based.
I was looking at it from a perspective of who would be likely to install WG and set up their own VPN. This is me guessing (that's why I hedged and said probably), but I suspect there is great overlap in the tinkering and DIY attitude of Arch users and WG users.
Mostly I was responding to the statement that Arch was a niche distro.
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.
WireGuard is great, but I think it's really undersold when it's described as being just a vpn. It's really an encrypted tunnel that is configured like a network adapter in the Linux network stack.
This lets you configure it with stuff like systemd-networkd and unit files, or easily spin up a tunnel with a few `ip` commands, and setup some simple nftables rules to do all sorts of stuff.
I do use it as a vpn as well, but it's so much easier to setup than, say, OpenVPN, where you need to create tun/br interfaces and then tie them together with a service, etc. That said, OpenVPN and other actual VPN software does more than just a tunnel (like pushing routes, config settings, etc), so WireGuard cannot replace everything by itself.
The documentation is rather sparse, but there isn't much to it either. The manpages have what you need to know and the rest is just general Linux network stack knowledge.
Is there an application for containers? E.g. a way to set up an encrypted tunneling interface between containers that would allow you to avoid using TLS between the containers?
Gravitational has built something called wormhole (clashes with magic wormhole, bad naming, isn't? Some other hold can be better) https://github.com/gravitational/wormhole
It can be used to replace flannel if encryption in transit is required.
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.
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.
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!
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.
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.)
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.
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.
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.
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.
I'm a bit baffled by WireGuard. From 10 000 feet, the protocol is similar to IPSec - encrypt packets, and send them over the internet using a connectionless protocol.
So why is it so much better?
Is it because it's a new and simpler implementation than what we have for IPSec?
Is it because the protocol, being newer, is simpler and cleaner than IPSec?
Is it because, being newer, it can use a modern ciphersuite?
Are there fundamental advances in the design?
One of the nice things about IPSec is that it's a standard. There's a reasonable chance that two endpoints written by separate parties will be able to communicate. Introducing a whole new protocol whose main implementation is its definition seems like a step backwards.
> One of the nice things about IPSec is that it's a standard. There's a reasonable chance that two endpoints written by separate parties will be able to communicate.
Having deployed IPSec between vendors, this is only "sorta" true. IPSec can be an immense fiddle to actually get running between two vendors for the first time.
One of the other issues when using IPSec between vendors (or even just be default) is that the actual overlapping ciphers/hashes that are supported or even just work are normally the lowest possible.
> Are there fundamental advances in the design?
First party roaming makes dealing with mobile and CGNAT much nicer, anyone behind a IPSec VPN on a home CGNAT network will have a bad time (often it won't connect at all)
Finally. It's code base is actually pretty small, allowing sane audits to take place. In my eyes thats a huge win. People who have seen the sheer size of strongswan or openvpn might appreciate wireguard in comparison.
IPsec is industry standard, but the whole IPsec stack and surrounding technology stack are very complex, different implementations (e.g. those Swans), configuration combos (phase 1,2 or in strongSwan sense - IKE, ESP, route-based, policy-based, etc.) and clients for different platform makes the whole thing a headache to deal with at large scale.
I've been using / working [1] [2] with strongSwan since early 2014, admittedly, the hands-on experience lifted my Linux / Networking skills to a whole new level, but at cost (countless hours burnt). It requires a broad range of skills, has a relatively steep learning curve.
> The company I've worked for (in pre-IPO stage), had 800+ strongSwan instances served as site-to-site VPN gateways inside AWS VPCs, they were single point of failure from a design PoV but that simple design (with health check and recovery mechanism of course) worked surprisingly very well over a period of 3 years (thanks to simple design and stability & quality of strongSwan). Personally I've been using strongSwan based VPN gateways to punch holes in GFW and encrypt network traffic until mid 2018, happy with it (<10 strongSwan instances to manage).
WireGuard is totally different design when I first migrated from strongSwan, simple, visible (interface, route-based), cryptokey routing, built-in roaming, small code base (minimal attack surface), performance (in kernel). Over time scalability and usability (all sorts of web UIs or GUIs) will improve, for large scale overlay we may better off with something else (nebula). For now officially it offers native client for most of the popular platforms.
For any new typical VPN (remote access, encryption in transit, site-to-site may not be as flexible as IPsec as I haven't done that, I used nebula instead to created an overlay) use cases, I'll pick WireGuard to start with ;-)
> One of the nice things about IPSec is that it's a standard
I would love to agree with this, but in practice, IPsec across vendors (or even across product lines from the same vendor) is often a nightmare. There are so many moving parts to IPSec, whereas Wireguard is drastically simpler.
From what I understand, Wireguard is intentionally non crypto-agile. Wireguard 1.0 has a mandated cyrpto suite, and in the future 2.0 or 3.0 would have mandated standards as well. As a result the connection negotiation is simplified and interop is guaranteed between providers.
Given the occasion, could someone write a paragraph about what downstream effects are expected by wireguard existing? So far I’ve seen mostly technical arguments for it. VPNs have become a more important piece of infrastructure now. The most significant approachability increase really came from mobile based solutions and auto pilot systems like Google’s Outline.
Will WG make a marked difference in stability, speed, approachability for normal users, or what can we expect?
Someone else can give a much better comparison than me, this is just to get you started.
Compared to the 80% use case of OpenVPN, Wireguard is:
1. Much less code. A few thousand lines of code vs lots more for OpenVPN
2. Speedier. WG does UDP traffic so there is less overhead on the protocol level for syncs acks etc.
3. Easier on mobile battery life due to decreased complexity
For one example use case comparing them side by side, see PiVPN, which I use to setup a Raspberry Pi Zero W on my home network, create a client key for my phone, open a single port forward to the pivpn server, download the wireguard app, scan the qr code the pivpn key generated, and poof, I can check a box and 'be' on my home network, behind my pihole, and with access to my LAN resources.
OpenVPN can do that usecase with pivpn as well but its more processor intensive and a little more setup vs wireguard.
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.
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.
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.
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.
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.
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.
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.
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.
I really hope WireGuard becomes a standard and get's included in the macOS/iOS and Windows kernels as well. Key management and and other fancy features could be left to userspace applications but having the basic wg capability in the kernel would be great.
I'm a big fan of Wireguard. I wrote wg-access-server [1] as an all-in-one wireguard VPN solution. I recently added some docs [2] and support for deploying with Helm. I'd love some feedback on here or on github. Give it a try.
I was looking for something like wg-access-server web UI when moving away from strongSwan. Found Subspace but id didn't work the way I wanted, settled pretty well with some shell scripting for my own use cases and happy lol
I think wg-access-server makes a lot of sense to people who want to self-host VPN on cheap VPS like Vultr or DigitalOcean, Lightsail, etc., it is simple, easy to deploy and use, flexible and scalable (if deployed to k8s).
I 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 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.
Now I really want to know when raspbian will get linux kernel 5.6. The most recent version of raspbian came out in February 2020 and uses linux kernel 4.19, which came out in late 2018.
it can actually work with 4.19 and the unstable repo.
I'm using 4.19.105-v7+ (to solve a macvlan bug in the default .97 and it works.
It's a pain to install the headers on raspbian though
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).
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?
Very exciting news, indeed! Finally WireGuard is in the Linux kernel 5.6 onwoards (will arrive soon in the next few days for those who are on rolling releases).
I've been using WireGuard to replace IPsec (strongSwan - the whole stack is way too complex, plus client configuration issues, outweighs the benefits) and OpenVPN (latency, bandwidth / performance is the biggest complaint) for remote access and mainly encrypting traffic from/to terminal devices when accessing the Internet via unknown hops/routes/path.
On the other hand, WireGuard is simple (cryptokey routing), modern, elegant, easy to configure & use, fast, and most importantly, reliable over the past 2.5 years, now even better without DKMS headaches ;-)
WireGuard clients for iOS (works as good as strongSwan for Android - which I missed a while ago) in terms of 1. on-demand 2. roaming between networks 3. power consumption / overhead. macOS and Windows ones also work very well.
Problems: WireGuard does not scale well when used for global overlay network use cases (nebula does a much better job for this purpose). Another issue for VPN providers: each client has a static IP configuration, which contradicts with privacy and surveillance, curious to see how Cloudflare's 1.1.1.1 solves the problem.
Last but not least: WireGuard protocol is easy to block. Therefore, I look forward to seeing obfuscation plugins / extensions for WireGuard, it will serve a much bigger purpose for people who live under censorship/surveillance (e.g. inside GFW) so as to protect privacy and get back their rights to access the `real` Internet.
Many thanks to Jason and the WireGuard team behind the scene!
Your first point: There's no part of WireGuard that inherently demands the use of a static IP address. You can run whatever dynamic IP protocol you want inside of it or outside of it. The entire interface configuration is dynamically configurable at runtime. We're working on one called wg-dynamic, but others have done others.
Your second point: Obfuscation protocols can encapsulate WireGuard just fine.
Really appreciate your input (and congrats!), Jason ;-)
I have been running 2 simple standalone WireGuard VPN servers for remote access and encrypting traffic (2 EC2 instances inside a VPC, scripted configuration). Admittedly I didn't dig deep enough to think about or leverage VPC's DHCP and/or DHCP servers running on other EC2 instances in the same VPC over the last 2+ years (facepalm), which also means, WireGuard has been set & forget (reliably working ;-)
Will dive into obfuscation and compare with (known to work) solution V2Ray (WebSocket + TLS + Web) / Trojan for next battle with the GFW.
BTW: Gravitational has built a WireGuard based overlay network CNI for k8s called wormhole [1] which can be used to replace flannel when encryption is required for in-cluster traffic across the overlay.
Search indicated that ShadowSocks (or its variants) can be used to tunnel WireGuard traffic, however, ShadowSocks is already on the way out due to continuously evolving GFW. I am looking to see if V2Ray is a viable option.
In the meantime, can anyone recommend a obfuscation proxy for Linux?
Any ideas how to get a client-server style VPN setup with WireGuard working with IPv6 so that it keeps working even if the public IP address of your VPN server changes? The configurations I've seen assign a statically configured IP address to a client. This works fine with NATted IPv4, but with IPv6, addresses are "public", so the client must basically know the prefix of the server to be able to configure a sane address, and if that changes, the configuration must be changed by hand.
The PiVPN project makes installing / administering WireGuard on the raspberry pi super easy - it has some scripts that nicely wrap WireGuard [1]. I'm not sure how generally applicable they are, but it might be a good starting point.
WireGuard on Linux has always been implemented as a kernel module (a very small one at that). If you've used it on Linux, you've used the code that has been included in Linux 5.6.
This is about the code being merged upstream into the main kernel repository which means that it'll likely be built-in to lots of distribution kernels and will no longer have the second-class status that most out-of-tree kernel modules have.
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.
If you've been using it on linux, you've almost certainly already been using the kernel version. Anecdotally, using it on my home LAN, the kernel implementation on linux performs much better than the userland implementation on MacOS. (Admittedly not the same hardware, the linux machine is a i5-3427U while the MacOS machine has an i5-5250U. I think the former might have an L2 cache advantage, but I'm not sure if that would explain the difference.)
Could WireGuard be a good choice for server-to-server encryption instead of TLS? (for example between a TLS terminating load balancer to the application servers)
What net benefits would you see that having? If I'm allowed to assume that you wouldn't use TLS because of PKI management concerns, I have a hard time seeing how using WireGuard in the large wouldn't have the same problems--you still have to build some kind of management platform on top that verifies host authenticity (ultimately including revocations and more). That is to say, WireGuard in the large will surely (right?) need supporting PKI.
Great to see 1.0.0 released. I’ve been using it for a VPN to my home network and have been really impressed with how fast it is (and how fast it connects!). The corporate VPNs I’ve used in the past we’re so much slower that it feels like a completely different league, although they support many more features of course.
I'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.
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.)
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.
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.
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 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?
'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.
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
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