WireGuard for iOS
lists.zx2c4.com
lists.zx2c4.com
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]
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.
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.
[1] Verizon Injecting Perma-Cookies to Track Mobile Customers, Bypassing Privacy Controls: https://www.eff.org/deeplinks/2014/11/verizon-x-uidh
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.
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.
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 have a portal that does this for openvpn:
https://github.com/secureweb/openvpn-portal
The code quality isn't great as it's my hello world golang project, but I think the idea is fairly sound.
100% simple and easy
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.
[1]: https://sshuttle.readthedocs.io/en/stable/how-it-works.html
Also, you lose information about where connections originate - to the recipient, it all looks like it came from the sshuttle host.
(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.)
The windows version has been "coming soon" for what feels like a very long time. Is progress being made on the windows version or has it stalled?
When setting up, use the QR method, makes it a breeze to setup a phone:
https://wiki.debian.org/Wireguard#A3._Import_by_reading_a_QR...
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.
It details the steps to setup udptunnel to tunnel Wireguard traffic over TCP. Hope it helps someone!
Additionally http://www.cs.columbia.edu/~lennox/udptunnel/ has a note saying:
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.
There is a third party Wireguard implementation for Windows: https://tunsafe.com/
However the Wireguard creator has some reservations about this third party client:
>We'll have an official Windows client coming out shortly
>9 months ago
>For those who are after Windows clients, the WireGuard project will hopefully have one quite soon,
>4 months ago
This is the problem.
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).
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.
[0] github.com/trailofbits/algo
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.
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.
There are multiple advantages for having a VPN module be in-kernel, such as closer access to network/crypto APIs and better performance.
But as I mentioned, WireGuard should really be the least of your problems (not to mention that there are userspace WireGuard implementations).
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.