I had been using wireguard-go (macports) on the Mac for a few months now and I'm simply amazed by the performance. Also using it on my phone. Weirdly enough when it's on my connection is more stable, probably because it bypasses the traffic shaping by my ISP through its UDP use.
I couldn't find any information on whether or not this uses wireguard-go internally? Or maybe even the Rust implementation?
It was a surprise because I’ve been using the same effect in my personal website [1] for several years (since 2003), as an Easter Egg during Christmas season. I got the script from this website (in case anyone is interested) [2]. I also have an Easter Egg for Valentine’s Day [2] which I’m always proud to show to my partner.
(Happy WireGuard user; using the go version on macOS for ages, using wg-quick, using the EdgeOS port on my Ubiquity router, and using the Android userspace version. Roaming simply works. Only thing which sucks is on Android the VPN gets lost when you update the software.)
There is a WIP (Net)BSD wireguard implementation, but that's a long way from something you could just use on MacOS, and the developers are unaffiliated with zx2c4.
There's also a WIP OpenBSD port in progress. Over the next week or so I've got some plans to try to start working more closely with these developers and make sure the BSD kernel ports are first party supported implementations.
If you don’t know of any efforts to make this available on FreeBSD, I’m interested in doing so. If you do: I’m willing to help. One end-goal is to subsequently enable pfsense.
This is the one you need. You only need root if you want to install the (Linux) Kernel Mod for better performance. If this isn't present the app will automatically use the Go (Userspace) implementation.
Although slower than the kernelspace implementation it's still faster and better than OpenVPN.
I've had a great experience deploying Wireguard using Streisand [1]. I'm excited to migrate to this GUI client, instead of using `wg-quick` in the macOS terminal.
With Streisand, I only needed to choose some options and input a few credentials. 20 minutes later, Streisand had created a locked-down, self-updating box dedicated to hosting nothing but Wireguard. I deployed to a $5/month Digital Ocean droplet.
AFAIK all software on Streisand does not auto update so you need to redeploy periodically (and the repo hasn’t been updated in a while, the main author has little time for it anymore) which isn’t great if you’ve shared certs with non technical users
Streisand installs around 70 different services. If all of them are not patched there’s a good chance your box becomes vulnerable over time. Remember, you’re piping all your internet traffic through this box.
I'm excited to hear that they are making a new TUN infrastructure for Windows. After the website redesign, OpenVPN doesn't even ship builds of Windows-TAP anymore and it is quite a pain to build, plus you have to sign it yourself. One of my current projects will need a TUN and we've decided to make it Linux only because its just too much work to support Windows. There is a new VPN provider API only accessible to UWP apps, but there is literally zero documentation or examples beyond the auto generated .NET API docs.
Indeed we looked in to UWP and got something sort of working there, but it's super new, undocumented, and has a lot of limitations that wouldn't have worked well for WireGuard, like roaming. Actually when we asked Microsoft for documentation and improvements, they asked us to sign an NDA, which obviously doesn't fly for an open source project. Plus, we'd then leave Windows 7 users in the cold, which AFAIK, is still an important target for enterprise.
Not speaking to the NDA issue, which is gross, but just to the Windows 7 users issue:
Windows 7 is currently under extended support (i.e.: critical security updates only) and that extended support ends as of January 2020. In other words: Standard end users have 11 months to migrate away from Windows 7 entirely.
There is a horrifically expensive option to purchase even further extended support from Microsoft, which a few large companies may do.
> There is a horrifically expensive option to purchase even further extended support from Microsoft, which a few large companies may do.
It's actually not that expensive[0]:
"Year one (January 2020 to 2021), that add-on will cost $25 per device for that set of users. Year two (January 2021 to 2022) that price goes up to $50 per device. And Year three (January 2022 to January 2023) it goes up to $100 per device."
And while this requires a volume license agreement[1]:
"Windows 7 ESUs will be available to all Windows 7 Professional and Windows 7 Enterprise customers in Volume Licensing, with a discount to customers with Windows software assurance, Windows 10 Enterprise or Windows 10 Education subscriptions."
it is not difficult or expensive to acquire[2]:
"While five licenses are required to enter into a new VL agreement, they need not all be for LTSC. According to a rep I spoke with at a Microsoft Partner, this combination would work as an upgrade from a Windows OEM license (i.e., it would allow a user who bought a PC with Windows 10 preinstalled to run Windows 10 LTSC instead): 1x Windows 10 Enterprise LTSC 2019 Single Upgrade Open Business $269.04 & 4x Microsoft Identity Manager - 1 User CAL - Open Business $7.81"
There are a lot of big companies with ThinkPad P-series mobile workstations on 7 that would cost quite a bit to replace. And the main concern isn't the cost of replacing vs. licensing, but of updating line-of-business workflows, custom apps, and user knowledge.
> OpenVPN doesn't even ship builds of Windows-TAP anymore
WireGuard's creator discussing OpenVPN's TUN/TAP driver and a possible alternative back in 2017[0]: The OpenVPN Windows kernel TUN/TAP driver is really super scary. That alone has a larger code base than all of WireGuard...
> There is a new VPN provider API only accessible to UWP apps, but there is literally zero documentation or examples beyond the auto generated .NET API docs.
I thought it was just me! Is this the reason why WireGuard decided not to use those APIs after all?
If I want to use WireGuard on Windows, what's my best option, currently? TunSafe? Looks like there's some development on Windows going on atm but no releases afaik
I use TunSafe for something like a year. It is great. Everything is pretty seamless. And with it I get better speeds than OpenVPN when connecting to Linux machine across Atlantic ocean.
It works great. As a user, I love that it's being distributed via the Mac App Store. The one and only nitpick I have is the lack of bulk import support of the config files, but that's something I can live without.
I'm looking forward to the Windows version. Thank you for taking the long and careful route with it.
Right-click on a (non-signed) program you want to run, and select 'Open'. Now MacOS will ask if you want to run this software or not, and it can remember this decision so you can just run it as normal in the future.
I know. I've done that many times. But what the WireGuard guys are saying sounds like it's something very different:
"Because it uses these deep integration APIs, we're only allowed to distribute the application using the macOS App Store (whose rejections, appeals, and eventual acceptance made for quite the stressful saga over the last week and a half)"
That's quite interesting - it's the first I've seen of a real world app being limited in this way and it is worrisome. I suspect if you disabled System Integrity Protection is would work, but not sure.
On iOS they've always been APIs like this - they only work via Apple approval and not dev or enterprise signatures.
I'm an iOS/Mac dev that's released a VPN app on both app stores.
The limiting factor is that the "Network Extension" framework is the way these apps work as VPNs, and currently Mac App Store distribution is the only supported method if you're using that framework (see #8) [1].
Macs are still macs. You can turn off SIP, disable AMFI & entitlement checks, then grant your app whatever entitlements you want and they won’t be verified.
I really really don’t recommend doing that; you’re giving up a lot of security.
A much easier alternative is to have a dev account, then you can just enable the entitlements in your provisioning profile for your dev devices (or personal devices). Most entitlements don’t require any approval for a dev profile.
Sure--I've no doubt there's some ugly workaround process to get around it, but I felt compelled to offer more information because it is usually the case that any Mac App Store app can be distributed outside the App Store relatively easily, except those that use the Network Extension framework.
I wanted to be sure the dev here is backed up that he's not making this up--this is Apple's restriction and not his.
> A much easier alternative is to have a dev account, then you can just enable the entitlements in your provisioning profile for your dev devices (or personal devices). Most entitlements don’t require any approval for a dev profile.
Yes, this is how we test on our own Macs before publishing to the app store. Although iirc those signatures have expiration timestamps, so you'll be re-signing and redistributing on some tedious interval (something like 30-90 days).
Jason, thank you for Wireguard. It is just awesome!
Which hosting provider is recommended for running your own wireguard server? I have tried various cloud providers like (digital ocean, google, aws etc)
I noticed that Apple ID and app store does not work when traffic exits via these cloud instances. Has anyone else faced this issue? Any solutions?
I've been running a VPN (currently WireGuard, previously StrongSwan) on a VPS through https://www.vultr.com/ for a little over a year now and have had no issues with the App Store. Signed-out Google Search, however, is a different story...
Do you know any good guides on configuring server to act as a vpn/proxy (routing mostly)? Regular wireguard articles don't cover this use-case at all, assuming reader know everything beforehand
For what it's worth, the RELATED, ESTABLISHED rule in FORWARD is a bad thing to forget; I was getting all sorts of interesting ICMP timeout errors because I didn't have it.
New connections from clients were allowed, but I didn't have a rule to allow related and established, which made some things work, but mostly not.
I'm assuming they are referring to the Network Extension API. It seems the forced transition to the MacOS app store has begun. I give it 10 years before apps from outside the store cannot run at all without disabling SIP.
macOS, like all Unix systems, already limits privileges for non-root users. What do you accomplish by placing limits on root as well?
If a malicious application gets root, you are very screwed. The app can encrypt most of your hard drive, monitor most keystrokes, do nasty things with your hosts file, and steal most of your personal data. It won't be able to directly inject itself into other processes and certain critical OS files we protected, but how relevant is that?
As I see it, SIP's main purpose is to (1) prevent non-technical users from (completely) hosing their systems by copying and pasting terminal commands from the internet, and (2) to protect TCC.db so that apps can't bypass Apple's privacy system.
If you're able to turn off SIP, you have enough technical knowledge than #1 isn't necessary. I suppose #2 may have some limited value, but not much.
If I am completely off base on this, feel free to educate me—but in my several years of research I have not come across any plausible scenarios for when SIP's protection would be helpful.
------
Edit: One other relevant note: Apple lets you selectively disable and enable parts of SIP. So you'd likely be able to turn off sideload-blocking (or whatever it is) without disabling SIP completely, if you want to for whatever reason.
It's more of a "prevent app developers from asking you to do it". A normal user that has to disable SIP is a lot more of a barrier than a normal user typing in the root password.
Normal users need UX to save them from owning themselves.
Exactly! But if you're an even slightly advanced user, this isn't necessary.
I'm a little frustrated by all the FUD I've seen spread in Apple enthusiast communities about how SIP is this super important security feature that should never be turned off.
My opinion is that if you have a reason to disable SIP, go ahead and do so with a clear conscious. You will continue to be protected by the privilege system that's in place for (basically) all UNIX's.
I'm not sure I understand this but if you prefer it in terms of strange analogies - you're walking past a construction site where they're building a highrise and see they're hammering a giant steel pylon into the ground. You smirk and say 'that won't keep the rain out!'.
Stated better: it appears to me that the consequence of a malicious app getting root is already so incredibly catastrophic, that at that point it makes little difference whether or not SIP is enabled.
Right, and I'm trying (and seemingly failing, sorry) to convince you you are looking at it backwards. SIP is not there to magically save you in a system where an all-powerful administrative account is compromised. The goal is to come up with a system that doesn't have something like an all-powerful administrative account, among other security improvements. It's only part of an effort to retrofit an existing consumer desktop OS to be more resilient to adversarial software - a long and arduous one that all makers of consumer OS'es are engaged in and have been for years.
Put another way, you’re saying macOS’s admin account is currently too powerful? Even if Apple is able to eventually change that—and it would take a while—it doesn’t make SIP useful for security as of right now.
Edit: Also, security be damned, I don’t want to use an OS without a proper root account! So while not entirely relevent to the discussion, I know that I would either continue to turn off SIP or move to another platform.
You get around it with things like SIP. Getting root on iOS is not, for instance, the absolute security game-over you are describing and it's a related OS.
Let's say you wanted an OS with better privilege control and other clever security doodads people have come up with in the years since merely having user accounts seemed like unconscionable oppression. If you don't care about backward compatibility much and start with Linux and a JVM you might end up with something like Android. If you start Linux and Chrome you might end up with something like ChromeOS. If you start with OS X you might end up with something like iOS. If you start from scratch you might end up with something like Fuchsia.
But what if you do care about backward compatibility? You then have a far more difficult, thankless and long-term job. If you start with OS X, somewhere along the line you'll have something like OS X + SIP + Sandbox + FDE. Or Windows NT + UAC + irritating autoreboots in the middle of the night. We're in the 'somewhere along the line' stage.
The issue is that normal users will not (and should not) disable SIP because it is complicated and scary.
Therefore it will become unviable for 99% of apps to be distributed outside the app store, so they won't.
I distribute an app outside the app store. It's free and open source, but not meant to be for technical users (it's art-related). I like people being able to use it, because I am a nice guy, but I also don't want to pay Apple $100/year and go through the hassle of putting it in the app store, if that would even work. My users are not going to disable SIP so if Apple continues in this way I really will be forced to put it in the app store (or more likely, abandon OSX).
The documentation mentions that an entitlement is required. However, this only implies that an Apple account is needed and the yearly dev fee is to be paid. Entitlements work outside of the App Store too.
Personally I'm happy to see WireGuard in the App Store, but would be concerned if Apple indeed limits the API to it. Could you elaborate on if distribution outside of the App Store is impossible?
I have tried to reproduce the issue and found that even though you can create provisioning profiles for direct distribution with the Network Extension entitlement, and the UI shows that all is fine, the provisioning profile does NOT contain the required entitlement.
After some digging I found a FAQ on network extensions by Apple [1]. Point #8 clearly says:
> #8 — On the Mac, can Developer ID apps host Network Extension providers?
> Currently this is not possible; only Mac App Store apps can host Network Extension providers.
Thus the missing entitlement is most likely not a bug (and the cert UI is just bad). This is not a technical limitation, just Apple with questionable politics.
I suspect the reasoning is to prevent malware/spyware from setting up an always-on VPN without the user’s permission (i.e. the recent Facebook/Onavo scandal). Without using NetworkExtension, a kext is needed (which now require fairly obnoxious user consent). And using NetworkExtensiom essentially requires Apple’s approval.
There are plenty of workarounds, but the issue is that when you want to pass quality control you have to play by they platform owner's rules. While not always nice on one hand, on the other hand this does mean that most users will be safe to install most software checked and distributed that way, without needing the intimate knowledge we have.
I totally understand that if Apple builds and maintains a PKI-based security model, they are going to want to check your stuff before allowing you in. If, on the other hand, the user doesn't care, they can simply turn off the security model or adjust it.
The problem is that on iOS Apple's "quality control" includes banning normal and fun human activities such as sex.
If that is now coming to the Mac as well then I will stop being Mac user and I will move away from Apple's platforms altogether.
Requiring Apple's permission to run WireGuard automatically means requring the permission of the government as well.
You don't even have to resort to China to see why that is bad. Many western governments are aggressively working towards banning various forms of encrypted communications.
That's not their quality control you are referring to but the content guidelines (censor). It's a choice they are free to make, and are probably mostly copied off some American idea on what should be public or not.
The problem you are running in to is that your ideas don't match their ideas and you want them to match your ideas (which they won't because they don't live in your world, they live in their world, which at this time is mostly the USA world).
If in your country the government would enforce some law stating that companies should not block sex in their content pipelines, then Apple, just like they do in every other country, will comply. This is also the reason they censor stuff in China, it's the law over there.
So while their ideas and values might not match with you, they do still have to follow the law. If you believe companies with a large impact should not block certain information from flowing, that is something you can enforce by law.
A company has to deal with the law, and cannot go and be an anarchist whenever it feels like it (but people can) because then they cease to exist.
If Apple did not block sideloading on iOS, they wouldn't practically be able to implement this kind of censorship in China and elsewhere. They would be able to remove it from the App Store, but people would be able to acquire the software via other means.
(This topic doesn't really apply to macOS though, just iOS.)
I agree, but now it appears to apply to the Mac as well, at least to some degree.
That's what I find so concerning. There has to be some general purpose computing device that allows me to take full responsibility in terms of security and in terms of complying with the law.
Other platforms often tend to imitate Apple. So if this is the general direction of travel then I find that very worrying
Someone downthread says the macOS signing requirements still go away fully when Gatekeeper is disabled, which is a simple terminal command. As long as that's the case, I don't think there's a real problem here.
It's hard to quantify "moving in a direction", but Gatekeeper was introduced nearly a decade ago and has always been possible to disable via a quick Terminal command. Apple did remove it from the UI in Sierra, so perhaps you could say that's a sign of things to come, but I honestly doubt it.
No. I don't want them to match my ideas. I want them to respect the fact that people have different ideas and values.
To allow that diversity of ideas to exist, it is necessary to keep the separation of concerns and legal responsibilities as it has been since the invention of the Mac (and the PC).
They make the hardware and the OS. I decide what software to install and what content to store. This has always been my legal responsibilty and it is on that basis that I decided to purchase my Mac.
If they change that equation, I'm out. I'm out as user. I'm out as developer. I'm out as decision maker and as a go-to person for others who make purchasing decisions.
Well, "your ideas" contains your idea of them respecting the fact that people have different ideas and values and that they should be allowed to use their platform in ways they see fit that might differ form the stakeholders that currently decide what is and isn't allowed.
The notion that they supply hardware and software and you then decide how they are going to work for you is no longer valid for the Apple products as they are. By default, macOS is being more like iOS now, which diverges from the generic idea of the personal computer.
This problem is of course far wider than just computers and Apple, more devices, services and companies are headed this way in varying degrees.
I suppose that means you are out as a user, developer and decision maker etc. Apple probably won't care unless you take 10 million customers with you at the same time. Anything less than 1 million is probably not even going to register on their metrics, and anything less than 10 million is only marginal. This is both the problem (our problem as users) and the benefit (their benefit as a company at scale) of this broad customer base many companies now have. It's not really a globalisation thing, but more a combined globalisation+commercialism+scale thing that makes this kind of thing common.
It's not that they want to make things less attractive to certain users on purpose either, that would be counter to their purpose of making money; it's probably far more likely that it's a case of Hanlon's razor. Take the way PKI is used to enforce some rules on hardware (i.e. iBoot and the A-series SoCs from Apple but also Intel's BootGuard on a much larger scale); it's not that they want to block people that want to fiddle with their hardware and software, it's just that this is the best they could come up with to defend against generic attacks. And it's far from ideal.
>Well, "your ideas" contains your idea of them respecting the fact that people have different ideas and values [...]"
I have ideas on different levels that shouldn't be conflated. I'm not asking Apple or anyone else to share my preferences and tastes.
But some meta ideas are a prerequisite for disagreement on preferences, tastes and beliefs. Without those ideas we are moving towards authoritarianism.
Once global companies become dominant enough, their decisions start to either facilitate or hinder liberty and authoritarianism, even under the assumption that they have to comply with the law at all times.
I don't think being seen to be on the side of oppression and authoritarianism against your own users is ultimately conducive to maximising profits.
> The problem is that on iOS Apple's "quality control" includes banning normal and fun human activities such as sex.
While being totally OK with (gun) violence. Hello, double (American) standard. Keep that double standard in the US. I don't want it in the EU. Thank you.
There are multiple ways and levels. The easiest is gatekeeper, which lives in the security settings. Next is SIP, which is a deeper layer (also PKI based) which cannot be changed while booted (which is a very good security model). You can only change this preboot or in the recovery environment. At that point, you may choose to disable SIP completely, or just parts of it (done using the csrutil). For an easier preboot option, you can use something like rEFInd/rEFIt to do this whenever you feel like it from a small preboot application.
Security-wise, that can be problematic, and I suggest you turn on EFI password authentication so it's not something everyone can do to your machine. This means you can still change the SIP settings on-demand per boot using a USB stick with rEFInd on it, but doing that requires you to chain boot off of that USB drive and doing that triggers EFI protection and requires a password before you can do that. Normal boot would not require a password and lets you use the system as-is.
I don't know a lot about Apple development, but there is presumably some way for developers to run these on their own machines for testing. An Apple Developer account is $99/year, including 100 iOS devices for sideloading, so I'd guess something similar applies to Macs?
A fairer assessment is that it replaces ESP (the stream encryption portion of IPSec) and a small subset of IKE features. If you look at the ecosystem of software arising around the core Wireguard protocol, much of it is a [poor] recapitulation of IKE.
Key management and PKI in particular, not bulk encryption, is the hard part of IPSec (in so far as its hard), and Wireguard doesn't actually solve that. I wouldn't be surprised if someone eventually hacked Wireguard configuration management into an existing IKE daemon.
This looks amazing. I currently use OpenVPN to tunnel into a Kubernetes cluster, it's great how simple debugging distributed apps has become due to being able to do that.
I wonder if I could use WireGuard to do the same, it appears to be much easier to set up.
Question: how many of you uses a crypted VPN Tunnel daily?
We all know that privacy is important and it will became more and more important in the next few years.
Does tools like WireGuard help in these cases? Or I miss the main focus? Should we all used a private VPN tunnel?
I run one most of the time (IKEv2). I'm in the UK, and do it on principle to stop my ISP storing details of every domain I visit on behalf of government agencies. If I were in the US I'd do it to prevent my ISP selling that data on.
(I also thought about setting something up for others, but this is currently 100% vapourware: http://digitalsnorkel.net/)
So I use Mullvad, that have WireGuard servers setup. Downloaded the config files (which work perfectly on Linux) and I can't get WireGuard for iOS to work at all. I get the VPN icon in the top left but I have no actual internet connection (on either WiFi or 4G).
Downloaded the TunSafe Client and the very same config files work perfectly. Obviously I'd prefer to use the WireGuard app though, but I cannot get it to work at all sadly.
Tunnelblick and Viscosity are _implementations_ of a protocol: OpenVPN. Wireguard is a different protocol than OpenVPN. Not just a different implementation of the same.
True, but all 3 are a frontend (Tunnelblick/Viscosity for OpenVPN and WireGuard for macOS is a frontend for the Go implementation). You could argue someone's asking for a comparison of the UIs.
FWIW, I've tested the UI, and I very much like it, except that the whole public and private key are visible on the screen. The Android version only shows it partly (could be my resolution).
Thanks for this, have been following the project for a while.
A minor annoyance, right now the usual option that allows to forward all traffic through the vpn is missing (the os and others put everything in an advance options pane accessible via button on the main screen) and route have to be configured manually each time... please keep this in mind for the next release ;)
I look forward to solutions to solve autoconfiguration. I love how with say OpenConnect, I just enter a server address and my address and auth methods are all configured automatically. Otherwise very much a fan of WG!
Looks great. I've been using WireGuard on the command line with my work MacBook and it's been solid despite the massive warnings about alpha software. I'll have to look into switching to this next week.
I'm using Wireguard in combination with Pi-Hole on a cheap VPS as a VPN on my iPhone, it's blazingly fast and super stable. Will be trying this on my Mac as well now.
Do you know any good guides on configuring server to act as a vpn/proxy (i.e. routing)? Regular wireguard articles don't cover this use-case at all, assuming reader know everything beforehand
This depends on your VPN service provider, not the WireGuard software - the software itself simply tunnels your traffic to the VPN provider, who then route it out to the internet. It doesn't matter if you use IPsec, OpenVPN, PPP, L2TP or WireGuard to send your traffic to your provider if their address has been blacklisted.
What WireGuard does get you is a much simpler configuration format for VPNs (IPsec is notoriously overcomplicated) and a modern set of cryptography choices (most other VPN techologies are old and come with legacy baggage, or strange TLS-like connection setup that then becomes its own thing like OpenVPN).
Pretty much any VPN be used to change your location. However, it depends where the server lives, what IP you get from that, and whether or not it's on a blacklist by netflix.
Wireguard is the protocol/tech, not a VPN Service Provider.
how would I go about implementing a killswitch for this? I'd like for it wait until I said its OK to either try to reconnect or allow network without WireGuard connection. I was very happy with how Tunnelblick would do this for shitty internet scenarios. Is something like that even necessary in this situation?
On the configs I've seen, "killswitch" is a few lines that tell iptables to stop sending when the connection drops. I don't know how tunnenblick does it, but this might actually, and I'm not joking, be a job for applescript? Since it looks like wireuard doesn't do killswitch on its own. http://krypted.com/mac-security/command-line-firewall-manage... might be a starting point.
Connect-on-demand does what you want. OSX will use this connection when it needs to network, and if it can't make the VPN start, the connection will stall.
Some of us with mac pros or hackintosh literally can't update to mojave, because of missing nvidia drivers. And high sierra was such a clusterfuck that I'm glad I missed out on it.
If you have downloaded it previously, it prompts you if you want to “download the last compatible version”. As long as you’ve downloaded it previously you can redownload it.
"Extended support ends in September 2019. iTunes, in August 2020" [1]
And while High Sierra (10.13) had its quirks [for which I could understand your response, plus all non Retina only work with 10.13 as latest, officially), Mojave (10.14) has been smooth. If not only for the dark mode (finally!).
We test with machines that have it, but we don't operate day to day on 10.14. It's more about offering backwards compatibility so the majority of users can benefit.
I couldn't find any information on whether or not this uses wireguard-go internally? Or maybe even the Rust implementation?
p.s. the snow on https://data.zx2c4.com/wireguard-for-macos-screenshots-febru... is pretty hilarious