I'm not sure how Algo does it, but the configuration is easy enough. I wouldn't do it without the post to help me, because it took a long time to figure it out, but copying two files isn't much hassle.
Cool. I'll try it out this week. My current VPN uses shadowsocks tunneled over KCPTUN, but I don't think I've optimised the KCPTUN parameters well enough, as the throughput is similar with and without it. I'm curious to see what throughput I get with WireGuard.
Unfortunately WireGuard is UDP only, so I can't even use it to get out through the university wifi firewall. 80 / 443 on TCP only.
At least OpenVPN, for all the criticism the article throws at it, has the configurability to pass through the various strange firewall rules that exist in the real World. Waiting eight seconds for negotiation isn't a big deal when the new and shiny 'replacement' doesn't have a hope of working.
Setup Wireguard on your server as though everything were normal. However, on the server, run this command (as a service):
udptunnel -s 443 127.0.0.1/51820
Then on your client run:
udptunnel -c [SERVER-ADDR]/443 127.0.0.1 51818
In the Client's Wireguard Config, where you would normally specify the server's address / port. Instead specify 127.0.0.1 51818. Finished!
Don't forget to open the firewall on the server's port 443!
Setting up udptunnel as a systemd service to auto start / restart only involves writing two short files! Wireguard uses a standard service file as well so you can simply require the udptunnel service as a prerequisite!
Personally, I find this style of combining simple components much more satisfying (and secure!) than the gargantuan complexity of OpenVPN/IPSec! Wireguard's simplicity means it is easy to have a mental model around how it functions and how it can be composed!
I wonder whether you could successfully mitigate this a bit by having udptunnel open multiple TCP connections to the destination and sending each tunnelled datagram on the connection with the shortest send queue.
You would get all kinds of interesting packet reordering issues, which can cause performance problems all their own.
I've sometimes contemplated just faking the TCP protocol entirely. Do the TCP handshake, then send "TCP packets" but interpret each payload as a datagram, acknowledge everything up to the latest sequence number regardless of whether any of them were lost and don't bother with any flow control or retransmissions.
It's a terrible hack but it would probably work at least some of the time.
In theory the re-ordering should only happen in the presence of packetloss, which is exactly what you want. Could be worth an experiment, anyway.
Your suggestion is how some "WAN optimisation" network middleboxes work (transparently terminating the TCP in the middlebox itself). To do that with Wireguard you'd have to implement that in the Linux kernel.
Since you mentioned security note the security implications towards the end of the page as this is actually pretty insecure without additional components. Also note this results in:
application data in
IP+<L4 protocol> in
IP+UDP Tunnel (Wireguard) in
IP+TCP
So securing the component mess and header bloat is becoming as bad as OpenVPN/IPSec which you abhorred. Still probably faster than OpenVPN though as that implementation is amazingly bad.
I think you've misunderstood. This setup is not insecure.
Wireguard authenticates (or drops) any packets forwarded by udptunnel. Once a packet leaves the Wireguard interface the attacker (or anyone else) can transform it however they like without impacting security properties.
This config does allow the attacker to make a TCP handshake to the server, but the data they send over the TCP wrapped connection could have equally been sent to the UDP port Wireguard is listening on.
Disclaimer: This of course assumes both Wireguard and udptunnel have no remote code exploits or other implementation errors. However, as we discussed, this is a much safer assumption than OpenVPN...
It does have one security implication: Wireguard never responds to an attacker. Your tunnel is responding to attackers, so now they know your box exists and can probe it for problems. Each TCP connection takes up memory. If you limit the TCP connections, they can run a slowloris attack and tie them all up.
So it's not a security hole, but it is slightly less secure.
I was more referring to the DoS attacks on the TCP stack than the spoofing attacks. https://nvd.nist.gov/vuln/detail/CVE-2018-5390 as an example. The attack surface is vastly expanded compared to Wireguard's default attack surface.
This seems more like a problem with your uni's firewall than with any VPN solution. If they're locking things down so hard, why do they allow you to set up an arbitrary VPN just by using TCP and :443?
If OTOH they want to allow you to use a VPN, they should allow at least some UDP traffic. The way God intended BTW because running VPN traffic over TCP usually means running error detection and flow control twice on top of each other.
Sure, some of the value of a VPN is running through misconfigured and outright hostile networks, hence various encapsulation schemes (over SSL, in DNS requests, etc), but only some of the value.
To be honest I'm a bit surprised vy the reactions here. This isn't an unusual configuration, I've worked in two other companies that had the same rules; nothing except web traffic even on the 'public' wifi. The latter permitted any device to connect but had absolutely no exceptions to the firewall rules. The corp nets did have an exception process but only for servers in the DMZ.
That sucks. Have you tried UDP over port 53? Also, I find ocserv/opeconnect much better for passing firewalls as it much more closely resembles HTTPS, I find OpenVPN is too easy to fingerprint. It opportunistically uses UDP if it can, otherwise it uses TCP.
Wrap it in stunnel if you can. Basically an https wrapper. Stunnel is increasingly useful for all kinds of VPN especially when you are traveling since more and more places are blocking vpn. Https is almost never blocked. Works pretty much every except China.
Buy a China Mobile Hong Kong 4G China data roaming SIM in Hong Kong airport (arrival concourse).
$15USD, rechargable - and 4G unfiltered internet in mainland China.
Yeah, and this is a pretty common situation on a lot of public networks. The whole reason I set up an OpenVPN (configured over tcp on port 80) was to be able to use irc!
Since net neutrality laws came into place a few years ago, I've been seeing it less and less. A few big ones (like the biggest rail company, NS, which offers free on-board wifi) got into trouble for blocking things like video streaming and it seems others took heed. Now most networks even allow TCP/25, and without any abuse that I've heard of.
I'm not sure that I don't, I've followed new IT-related laws in the Netherlands closely so I'm pretty sure I know what's included without looking it up. I'm more sceptical of someone who says "you have no idea" without anything to back that statement up. But for other readers, I'll elaborate.
Blocking UDP is not treating all traffic the same. Even if the law would be about treating services equally and not any IP packet equally, then it still has a different impact on services like VoIP (which are often UDP) than it does on other services. Blocking certain types of packets is not compliant with net neutrality -- at least, not in the Netherlands. If there is a different definition whereever you come from, please tell me about it.
Net neutrality is and has always been in any discussion in Switzerland, Germany, Austria, the US and everywhere I have seen else about ISP and ISP abusing their position in the market.
I have never once heard anybody claim that private institutions are not allowed to shape their own network traffic.
Unless you show me Dutch law that clearly spells this out, I will not for a second believe that it is illegal for a university to block certain protocols.
If what you say were true then pretty much every single private organization would be operating illegally, anybody that runs VoIP, blocks UDP or any other way to shape the network.
I have a feeling it's a bit more nuanced than that otherwise you're telling me a University in the Netherlands can't run a firewall on their internet link and they need to have all public addresses to get around the fact that no device dynamically NATs all L4 protocols.
I'd be willing to bet my lunch that there are exceptions for private, government, and educational institutions or that there is an exception related to security services.
> you're telling me a University in the Netherlands can't run a firewall on their internet link
Any blocks should be necessary/essential for network stability or security. If I have evidence that a trojan is using tcp port 1337, and I am not aware of any other application that uses it, then there is no problem blocking it. In practice, of course, malware would be crazy not to use tcp/443 or tcp/80, so blocking ports is rather pointless these days anyway.
As for network stability: reasons like "by blocking VoIP we can sell our services and use that money to make our network more stable" are not good enough, of course. There has to be a concrete reason why {whatever you want to block} will benefit the network.
> and they need to have all public addresses to get around the fact that no device dynamically NATs all L4 protocols.
I guess since there is scarity in v4-addresses, it's not reasonable to use public addresses for each individual, so "blocking" incoming traffic (or rather, it being unrouteable) shouldn't be an issue. It's essential for the network's operation.
Firewalls have stateful inspection and handshake inspection capabilities for known protocols on known ports. They also have URL filtering, IPS, DDoS protection, and threat monitoring. This is the big difference between an organization like a business/university vs an ISP. I wasn't talking simple ACLs, that only requires a basic switch.
Having been running WireGuard in my router for a couple of months now I have to say it's just the first ever VPN to offer no bandwidth penalty and a very easy setup. Now I have IPv6 through the VPN, all traffic from the house is routed through anonymous servers and I've had no problems with the connection dropping. Very nice work here.
> I have to say it's just the first ever VPN to offer no bandwidth penalty
By protocol design it incurs a 4%-~50% (1500 byte and 64 byte packets respectively) bandwidth penalty over the internet due to headers. The encryption of the payload is extremely fast though.
I've been trying to setup OpenVPN for ages, and it always eats about 60-80% of the bandwidth. No matter what I try with it, I just cannot get the full speed of my internet connection through the protocol. With Wireguard I haven't noticed any difference. fast.com is as fast with or without WireGuard. I have to say it's the first time in my life I see it working this easily.
OpenWRT has WireGuard support, so also, every router you can put an OpenWRT image on.
EDIT: I'm using it on my Netgear WNDR3800, and my grandmother's Sitecom WLR-4000 (which is a rebranded Sitecom WL-351, which is a rebranded EnGenius ESR9850).
And if you're feeling like a fun weekend hacking project it's also available on OpenBSD which runs on the EdgeRouter including support for the onboard packet accelerator.
To be fair, then your bandwidth penalty just comes from something else.
(I run a large number of ERs, mostly because you can easily run so much other software on the hardware -- but they're not great devices if you need performance or reliability. "You get what you pay for" absolutely applies.)
WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing and the protocol is still subject to change. We're working toward a stable 1.0 release, but that time has not yet come. There are experimental snapshots tagged with "0.0.YYYYMMDD", but these should not be considered real releases and they may contain security vulnerabilities (which would not be eligible for CVEs, since this is pre-release snapshot software). If you are packaging WireGuard, you must keep up to date with the snapshots.
>AFAIK Jason does use wireguard for himself now, but is cautious to recommend that to everyone.
For me this means he's appropriately cautious for working in security-minded applications like this. A lot of VPN providers would probably release something like an alpha release.
I'm not sure if this was meant as a jab or accurate, but btrfs is a good example. The core of it is stable, but there are a few features which are unstable/experimental, yet still included.
This question comes up in every discussion of WireGuard. Jason's answer is that updating the web page is a low priority for him. You should use WireGuard if you can.
> Jason's answer is that updating the web page is a low priority for him
I really don't understand this. Why not just update the webpage and eliminate having to give the same response every time, since it seems to be asked a lot?
Well, if it's ready, but it hasn't been a long enough time then maybe we avoid rushing everyone to wireguard until it's been tested in the wild more by those who read the mailing lists and etc.
I feel like it’s natural for anyone even close to the security industry to be very hesitant to say a product they created is secure or complete. Even Socrates ended with “All I know is that I don’t know”. Which interpreted means: use it.
Linus never was a big fan of serious security matters. He is interested primarily in simple, small code that is simple to maintain, code that doesn't require any serious changes in other parts of the kernel, that's it.
Does anyone know if any commercial VPN providers implement WireGuard yet on iOS?
> "An iOS app is available in the WireGuard repository, but as it isn't in the App Store yet. It's probably not going to do you any good unless you're an iOS developer yourself."
The article references code for iOS apps but also states that "it needs to be baked right into the kernel for that to happen.". Would iOS apps also need the iOS Kernel (say iOS 12.x or iOS 13.x) to include WireGuard to take advantage of some of the speed advantages over OpenVPN?
Is there any "easy" algo-like setup? I've checked but all of them still seem to involve a lot of steps. I could do it but I'd prefer if there's some quick start to test it out.
Sends a tiny bit of dummy traffic every N seconds, keeps a NAT router from just forgetting about your client's state. I imagine Algo doesn't include that line because the generated config is for Android phones but for a laptop or desktop behind NAT, you pretty much always want it. This is especially true for things like public WiFi where the routers can be particularly keen to forget you.
Edit: There's a blurb about it on the website as well that is a little less handwavey than what I typed:
What Algo does now seems technically correct (the best kind of correct!) since it essentially says WG is for Android. I've added the issue though, for when more desktop-y clients are officially supported.
It's a nice enough guide but its default set up is something 97.30133% (recurring, of course) users aren't trying to do with a VPN - reach a home computer from their server. What most people want is to shovel all their client's traffic through the server. This is also described as a sort of afterthought, but I think for most people, it's the thing they're trying to accomplish when they want to set up a VPN.
I wonder how it works in ChromeOS, anyone tried it? I had OpenVPN working for a while, but the debugibility of it was pretty low, it was a pain to set up. I was always turning it on and off, unlike my Linux laptop where it would just always be on and working. That's using the built in OpenVPN, not an android app. I wonder if setting it up in the "ChromeOS centrally managed" mode would help any?
I'm really using my chromebook a lot these days at home, but wish I had a better VPN option for it.
Not yet, but it's in the works. There currently isn't a stable userspace implementation of Wireguard that would work on all the major platforms anyway :(
When someone provides instructions to set up a WireGuard server on my Linux server and a client on my Android, I might just buy into that "easy setup" story.
There's plenty of tutorials, including a couple posted in this thread. It's unfortunate that you had a bad experience setting it up, since it is usually pretty simple. But I think the "easy setup" is relative to the setup for OpenVPN, etc.
I love the Android client. OpenVPN used to consume some 25% of the battery life. With wireguard it's next to nothing and it's very very quick to connect. Great stuff!
Regarding the whole-protocol versions instead of mix and match negotiation: is there a reason that wouldn't have worked for TLS? At least technologically; I'm sure it was a non-starter politically.
I'm just wondering if there are any actual downsides to this scheme. It seems like such an obviously good idea that I'm second-guessing myself.
It would have worked fine for SSL (now TLS). Wireguard has the advantage of being able to learn from decades of experience with real world SSL/TLS vulnerabilities — the advantage of hindsight.
SSL and especially TLS are used in lots of different applications. So either most of them don't get the features they want in this scenario, or they all use mutually incompatible protocols.
The no-negotiation approach also means if things change you can't find out why you can't connect. Maybe you need to upgrade your software? Or downgrade it? Did you change any settings? It's a mystery!
It was required to comply with US laws against exporting strong cryptography. In order to have a global standard the protocol had to be decoupled from the crypto implementation and clients had to be able to negotiate down to the (broken) crypto approved for export.
What bothers me in the Article, the official documentation and almost all guides for wireguard is that they ignore ipv6 completely.
They either result in a leaking vpn or bad working one where all ipv6 connections fail.
Someone can correct me, but I would prefer Tabulation Hashing to SipHash, even though SipHash is by DJB. Tabulation Hashing offers optimal guarantees and performance, and it's much simpler.
Automatic roaming seems to be the killer feature that nobody has noticed - I know IPsec has this to a degree but Wireguard looks like it works much faster.
If the kernel code is vulnerable then the attacker gets full control over your system. They can also easily hide their presence. If the code is in userspace, the attacker won't even be able to read your files if you run the daemon under a separate user account. They only will be able to mine Bitcoins or use your computer as a proxy for a short time.
This is what Jason said the last time it came up on the mailing list[1]:
"I think that given the WireGuard building block, it's certainly possible to build a 2FA framework around it. And I do generally like 2FA and short-lived credentials and such. Probably after getting the implementations buttoned up -- kernel mainline, windows, etc -- I'll turn a bit of attention to expanding tooling and full packages around the simple wg0 interface."
I don't know much about the fundamentals of networking and security, just asking - can a Linux server with WireGuard installed to be able be detected by GFW (the Great FireWall) and thus get the IP address blocked?
On the other hand, I couldn't wait for the Windows client.
So the control program is just "wg". We only have one namespace for commands so using a two-letter combination for something as obscure as controlling VPNs is not very clever. Two-letter combinations should be left to user aliases and core things like cp, ls, df.
I sure use "wg" more often than I use "ul", "as", "bc", "eg", "ex", "gc", "id", "ld", "nl", "od", "pr", "sg", "tc" and "ul".
All these courtesy of `ls {,/usr}/{,s}bin/??`. In fact, there are only 44 two-lettered commands on my (Arch Linux) system right now, so this particular realm appears to be very sparsely populated. (Not counting shell builtins though.)
I feel I gotta mention Tinc https://www.tinc-vpn.org The article mentions it's existence but then ignores it...
It is as easy to use as WireGuard and has two advantages over wireguard. 1. It will automatically mess, and find the best path. 2. It has a far wider range of platforms supported than wireguard.
b) There are no claims about downgrade resistance. The manual specifies the new transport protocol is used if both clients support it and both have changed their configs to enable experimental mode. Can an attacker still force them to connect with legacy mode?
c) Users have to ensure every single config on every client has the correct setting.
d) It still doesn't have the identity hiding features of Wireguard. (Someone observing your network traffic can see which servers you are talking to from the transmitted signatures)
Huh, interesting... I am definitely going to be doing some reading about this one. I wonder what the logic of the project maintainers, whom seem to maintain it, have in keeping with this method of encryption.
Tinc is really cool. I like that you can give it a partial mesh and it will figure out how to create a full mesh from it. A few years ago I was talking to the author, Guus, about using WireGuard as the underlying backhaul in Tinc while preserving the neat Tinc meshing magic. I've since gotten super busy getting the core WireGuard stuff completed, but at some point I'd really like to circle back to Guus and make something like that happen.
That would be awesome. I think WireGuard + Tinc + userland windows + iOS support would be the ultimate VPN solution. Bringing WireGuard back hail to Tinc would bring that one important step closer.
Tinc is also completely userland (as opposed to implemented in a kernel module), and therefore slow enough to be practically unusable unless you're on a very slow connection.
Compare this to something like IPSec, where the userland is typically only used for the control part; once a connection exists, the packets don't leave the kernel, so no context switch needed.
I dont know about tinc, but we've benchmarked ZeroTier which is user land and gotten results close to IPSec. The tun/tap overhead is low. It might matter if you are pumping serious traffic, like encrypting a data center or leased fiber line.
If tinc is crazy slow I suspect it's an implementation issue.
4096 bit keys, comparison, aah. Sounds like the crypto stuff is really badly off in this article. Key length alone doesn't practically mean anything. Classic VPN lies and hype.
The reason OpenVPN (and almost all VPN solutions) use such ridiculously long keys is that you don't have to brute-force them. An actual cryptographic attack on the algorithms commonly used for VPNs (or for HTTPS connections to websites) looks a lot more like a dictionary attack than a brute-force attack; you can discount great swathes of the problem space without having to actually try them.
That explanation seems fine to me. It's not an explanation of the underlying math but it doesn't need to be.
You are probably getting downvoted because the article points out exactly that. The author was erroneously thinking that a big key is necessary - and wireguard doesn't provide one. Which made him discover that fallacy.
https://www.stavros.io/posts/how-to-configure-wireguard/