I’ve been using the TestFlight beta for a while now - since it was first announced - and it’s been a great experience so far. The recently added option to activate on-demand is great, as it means I can now force VPN for any WiFi and/or mobile data connections.
The primary niggle I came across was transferring the keys between my host and the client, however after a bit of tweaking I found it far easier to just utilise the QR codes option. For those interested, I wrote about my experiences on my blog[0]
Great write up, thank you! Looking at your blog post, it seems that once I've followed your guide, I only need to forward port 51820 from my router to the WG server. Is that correct?
Is your threat model that you trust your ISP for your wireguard server more than the mobile ISPs? WiFi I completely understand but 4g providers seem to be on par if not better than cable companies in the us when it comes to molesting your traffic.
Depends on the country I am in as to whether or not I want to VPN whilst on a mobile connection (whether that is for just having an IP in my home country or don’t fancy my traffic going over their wires).
It is primarily for public and/or untrusted WiFi connections, or so that I can take packet captures of iOS applications easily without a jailbreak or connecting the phone via USB to a Mac.
I also use the setting to automatically switch on when going to cellular. I use it because I have a PiHole for DNS ad blocking that I wish to continue to use when on cellular. Being on a VPN is the only way to do that on iOS.
I installed OpenVPN on my DO box after a hotel (Legoland CA) tried to MITM Dropbox, Reddit, and a few other sites. The app/browser caught this, but it rendered them unusable.
But in general, yeah I’d trust DO over Comcast or Verizon. I believe one of the US cell phone providers have been caught injecting tracking cookies into http headers in the past and selling customer information fits nicely into their business model.
I tend to only use it when I’m on sketchy WiFi networks though.
That's pretty much my threat model. I tunnel everything over a Digital Ocean box, where I can assume that three letter agencies have access to my traffic but be reasonably confident that my ISP isn't building up a profile on me that it may be sharing with third parties in my country like insurance companies or credit agencies. I can also roll my IP every few weeks which might assist in messing up various tracking/profiling measures.
My initial concern was that it would slow down my browsing because my VPS is in another country but I haven't noticed much difference.
I just ran through this - works flawlessly. One peculiarity that might help someone else in my shoes: I was connecting to my VPN node through Terminal (with Solarized Dark) on OS X and generating the QR code with the suggested command but the result was a little 'off' somehow and didn't read as a QR code to my phone. By replacing 'ansiutf8' with simply 'ansi' I was able to get a smoother, readable QR code. Just a heads up in case someone else follows this excellent guide and gets the same issue - I fully blame Solarized ;)
Any plans for 2FA/MFA? A lot of businesses these days prefer or even require it for remote access. That would then make WireGuard a good alternative to OpenVPN in those environments.
That is something that would be built on top of WireGuard. I think some people are working on such projects, but the whole point of WireGuard "core" is that it's incredibly minimal in what it does.
I for one applaud that. Strongswan and OpenVPN both have so much legacy cruft it's hard to make sure the VPN is secure - that the OSs implementation isn't incredibly out-of-date and I haven't made grave configuration mistakes, not even talking about how much harder Strongswan is to configure compared to Wireguard.
I could see the server side effectively operating like a public wifi hotspot and force all routing to a disclaimer type page.
Then you could implement the 2FA there (or even proper username/password logins, which seems weird for WireGuard). If you enter the correct 2FA code, then your IP is no longer blocked.
I know phones (and computers) can handle this when connecting to a new WiFi SSID, but do they also run their check when connecting over VPN? I might have to try that.
You could write a web portal that generate the wireguard configs on the server and offers the user the client config as a download.
The portal then can hook upto to SAML / OIDC endpoint, use claims / groups / roles to offer specific profile configurations and you treat the keys in the configs as temporary tokens, as you attach an empiry time to the profile such as 8 hours, so your devs need to download a new configuration every day.
I can confirm automatic captive portals work on most wired devices. Those that don't will have to go to http://example.com or similar to be redirected. Word of warning for anyone that implements this: your DNS portal needs to be internal and captive as well.
I believe another contributor wrote a Go user-space implementation and Jason decided to build off that for the PC user-space implementations and Android and iOS. So basically, because it was there.
I set up Wireguard with this script [0] and made the jump from OpenVPN earlier this week (using Testflight). Has worked wonderfully throughout (once I added a DNS server to my client config - that one bit me!) and I'm now a convert.
Thank you for that link. I tried manually setting up a VPN for my phone. It didn't work. After deleting my old wg0.conf (and adding the DNS to the client) it worked.
Sure, but WireGuard has several other benefits (security-wise and operation-wise to sshuttle). sshuttle is a "poor man's VPN", WireGuard is a next generation VPN.
That’s a nice sound bite but it isn’t really convincing for people that don’t know what wireguard brings. Is there a short comparison article you could point to that highlights the differences?
One of the most obvious features is that you get roaming with WireGuard (like Mosh) which I don't think you can get from sshuttle (it might be technically possible to add, but I don't think it supported it last time I used it). It also allows for management of the VPN interface like a regular interface (so you can set iptables rules and other complicated network setups using it), rather than relying purely on proxying. And you don't need to give people SSH access in order to use it.
One major point over ssh is that: "WireGuard securely encapsulates IP packets over UDP." - so you avoid all the issues of tcp-over-tcp;wireguard is a "real" VPN.
Agreed that sshuttle is probably the easiest VPN I've ever seen, but from my experience its performance leaves a lot to be desired. WG is a little bit more involved to set up, but is extremely high performance.
People using WireGuard: how well does it work in public networks that only have a few select open ports (http/https/openvpn…) ? Does anyone have a workaround (e.g a reverse tcp (+tls/sni?) proxy on port 443?)
Wireguard packets on port 443 looks like malformed QUIC packets. Any firewall that is doing protocol inspection (for L7 policy enforcement) would typically be configured to drop malformed packets. Wireguard would get blocked by such firewalls.
Proxying on 443 would 100% work, I can say that without trying. The only case that would not work is if the firewall would do any deep packet inspection to see whether the connection setup resembles https. That of course would also be easy to circumvent, but I don't think any firewall would go so far.
Have you actually tried this? I expect that it wouldn't work very well. There's a bit of common wisdom of "don't do TCP over TCP"; the reason WireGuard uses UDP is that UDP faithfully forwards-up-the-stack the unreliability of the underlying Ethernet network. This unreliability is important to the proper operation of TCP flow control for TCP streams sent over WireGuard. If you just plopped those UDP packets on to a perfectly reliable stream (like a TCP stream), it would mess up the flow control for TCP connections going through the VPN (unless something in the stack is taking special care for this scenario).
(I'm very interested in solutions to "I'd like the unreliability of UDP so that I can send TCP over it, but I only have TCP" problem.)
Been using it for some weeks via TestFlight, it's really solid and works without a hitch. Great to see it on the actual store. It now has "on-demand mode" and transitions seamlessly between Wi-Fi and cellular.
When setting up, use the QR method, makes it a breeze to setup a phone:
I've been meaning to try it out, but the lack of an iOS client has held me back. Perhaps now is a good time to start :)
I wish there had been some progress with the EdgeOS port, specifically with hardware offload. a Ubnt employee was looking into it a year ago, and then nothing. The current (major release) beta of it doesn't mention anything about it either.
pfSense probably won't implement it natively until it's part of the FreeBSD kernel. If you want to run it on pfSense now you could bundle the userspace Go implementation as a pfSense package though.
I know someone do use wireguard to bypass the GFW. It's not blocked at the moment. However, a concern is that the UDP-based protocol is not hard to detect.
Anyone have experience with making this work? I tried starting it on the server I have WireGuard running on and it fails to start because it also wants to bind to the UDP port WireGuard uses (even in server mode).
UDPTunnel is designed to tunnel RTP-style traffic, in which applications send and receive UDP packets to and from the same port (or pair of ports). It does not support request/response-style traffic, in which a client request is sent from a transient port X to a well-known port Y, and the server's response is returned from port Y to port X.
Which from what I understand is exactly what WireGuard does.
I used wireguard with a personal VPN [0] set up on DO. Worked great, although I occasionally had to tear down & set up a new server when it was detected.
It's billed on Streisand's Github page [1] as working there. I'll be giving it a spin in February as an alternative to Shadowsocks and Anyconnect. Just need Wireguard on Windows now!
Another well-known problem is expecting people you're not paying to give you something extra after they've already given you great software gratis under a free software license.
Apologies if you're a paying supporter, but then you would already know what to expect and when.
https://www.patreon.com/zx2c4
I'm personally happy to wait for the quality official client with upstream support (even though I gave a try to TunSafe without expectation to use it in the long term).
My concern is zx2c4's attitude. Especially towards TunSafe and the author. He claimed that there are interoperability and security issues, only because it was closed-source, firstly. No proof was given though. Then it became open source, haven't seen any claims of security/interoperability.
An independent implementation of Wireguard is a good thing, but zx2c4 apparently doesn't want that. I can't explain the zealous fight against it otherwise.
TunSafe's author Ludde also made µtorrent which he so often says. But depending on the version you have it's either good or infested with adware. Although the later one is not his fault anymore, I still wouldn't mention it without the version number that was still good.
This. I don't know why this is receiving downvotes, but wireguard truly is a life saver. Just needs a desktop GUI interface and it would make a difference to thousands.
I don't mind the downvotes, I just wanted to encourage the author (since I know he'd be reading it) and everybody else who are fighting for people's privacy. I realize this kind of encouragement is usually more welcome at Show HN, but well, WireGuard are already so big and has achieved so much that this is basically a Show HN for them.
Edit: hopefully it goes without saying that the downvotes are/were aimed at me for stating the obvious (with little relevance to the topic), rather than people actually disagreeing with the what I said.
Nokia 7 Plus, starting 7am, now 4pm, tells me wireguard ate 27% (1026mAh, using 4G most of the time: 9am - 4pm).
Though I'm not sure how much data I actually used. My phone does persistent keepalive so that I can use https://messages.android.com/ . Usage should go down quite a bit if you don't need remote connection to the phone.
Not directly comparable of course because it's WiFi only, but my iPad reports 3% over the last 10 days (much of which would have been Wireguard being open and exporting logs when I was debugging whilst setting it up) and 1% over the last 24 hours. I was also concerned about this but it's been fine.
Yes, but being in the kernel makes it much faster, since you don't have to copy packets between user space and kernel space. It also allows you to use WireGuard from early boot, as well as allowing you to manage it like a real network interface (you can do this with TAP interfaces but it's less clean).
There is a userspace version available if you really don't want to use a kernel module (this is what the Android app uses if your kernel doesn't have WireGuard).
Also, WireGuard is an incredibly small program, less than 4000 lines. You could audit it in day, and has been extensively fuzzed (and was designed to be secure in many aspects). I would be far more worried about buggy network drivers than WireGuard.
In order to listen (and forward) all network traffic you need privileges over the network namespace that you want to forward packets for. In most cases this ends up with you running as root. You can use proxies but that defeats the point of a VPN -- that all traffic is forwarded.
But as I mentioned, WireGuard should really be the least of your problems (not to mention that there are userspace WireGuard implementations).
The primary niggle I came across was transferring the keys between my host and the client, however after a bit of tweaking I found it far easier to just utilise the QR codes option. For those interested, I wrote about my experiences on my blog[0]
[0] https://grh.am/2018/wireguard-setup-guide-for-ios/