> Wireguard won't upgrade itself if it's still running…
This is not unique to Wireguard. I’ve had this happen with the Lockdown app too.
This is an Apple problem. Apple should notify you that the VPN app needs to close in order to upgrade then offer you a simple way of doing that.
> I don't know exactly, and I don't really care.
This about sums it up. This is a rant and it’s difficult not to just close tab half way through.
I have had the opposite experience to OP. I have the macOS app installed on several Macs (laptops and desktops). They have all worked so well to the point that I even forget Wireguard is running. On top of that I upgrade macOS almost as soon as Apple releases a new version.
It is true that for updating WG you need to first disable the on-demand setting (probably only on Big Sur). But to me that is such a trivial hiccup considering it is free and generally bug free! On the rare occasions that I have had a non-trivial issue looking at the log file has provided clues.
My VPN cost is only about $5/month as I run my own instance of WG server in the cloud. Worth every penny! It is possible it could be lower if I use one of those #3.50/month AWS lightsail instances but I never tried.
Just as a thing to keep in mind, if you're using Algo (or any other vpn software) with a commercial cloud provider, you'll hit more captchas and blocks than usual. For example, going to walmart.com will give a captcha page before being allowed on their website. Some websites will return HTTP 403, and some will just timeout.
I use a Debian OpenVZ based VPS for this and uninstall or disable any services except the one I want (surprisingly this isn't the default :(, check what is listening with "ss -l46n"). The advantage of OpenVZ is that kernel patching is the job of the provider, so if you only have one service listening remotely then you should be ok as long as that service is ok.
I use SSH so far since WireGuard isn't supported yet. I also configure SSH to only allow the type of connection I want to use: public key authentication only, ports 80 and 443, plus (on both local and remote sides):
Install unattended-upgrades and edit /etc/apt/apt.conf.d/50unattended-upgrades as desired. For SSH proxy, locally set "ALL_PROXY=socks5://127.0.0.1:2000" (with DynamicForward localhost:2000 locally). Or change socks5 to socks5h if you want DNS to be handled on the remote system, however this will prevent uMatrix and other blockers from getting DNS info needed to avoid considering some 3rd party content as 1st party so it is better to set up encrypted DNS locally (I use stubby but with just the provider I want). Many applications check ALL_PROXY these days but not all and I think Firefox needs explicit settings to use the proxy.
I use ramnode.com's $15/year OpenVZ and it works great like this for getting an encrypted connection past your local ISP and/or wifi (I think they ask for everyone's ID when you start). There are issues with some websites due to the IP address, but it is not nearly as many as using an annonymous VPN from what I've heard.
How else can you get good at security? I guess you could read, but at some point you'll have to practice. And I never said you need to practice with sensitive information.
“No activity logs” is impossible to verify, and “hides your device’s activity” is basically untrue unless you do some gymnastics with the definitions of words.
a. I don't trust any VPN provider's claims. Plus I wanted more control including ability to turn on/off logs if needed. As an experiment I started with an AWS lightsail instance. It worked so well that I now I don't feel I need anything with more resources (up to about 10 clients). That doesn't mean I trust AWS entirely but for now I will live with it. I like using a CLI and AWS's browser based CLI is pretty good (but be wary of copy-paste snafus).
b. The other reason I went with a cloud provider like AWS is that their static IP seems to be whitelisted fairly well especially with their own service - Amazon Prime. So I have had not problem watching videos while traveling. Also in the past macOS and iOS updates were problematic via VPN. But that seems to have gone away. Maybe because they bypass VPN? I don't know for sure.
c. Many of my friends have been asking for help. I figured if I went with one of the big 3 cloud providers it would be easy for me to basically create an instance image preloaded with all the scripts and WG etc. that they can then run from their own accounts.
d. The big 3 cloud providers uptimes are far better than many of the VPN providers.
Why are you using a VPN? I think the main reason (now that Netflix et al block all VPN IPs) is generally that you gain privacy from your traffic being mixed in with hundreds/thousands of other people's originating from a single IP. With running your own VPN server, your IP is trivially tracable back to you as an individual. So now what do you get - encrypting vs. your ISP and/or country hopping (with no streaming except amazon)?
Not OP, but as the name suggests, a VPN is a virtual private network: you can use it to create a private subnet from where you can securely access your other computers/resources, even from a remote location.
For instance, at work we are mostly remote, and use a VPN (OpenVPN here) to access the local network at the office with our on-premise build servers, and it also allows developers to work together sometimes (one running a debugging server on their dev laptop, another debugging the client from their own laptop as if they were sharing a local network, when actually they are hundreds of miles apart)
Thanks, but I don't need the wikipedia summary of a VPN.
It didn't sound ad all like the OP was using his VPN to dial into work. He was dialing into a purpose-build VM which wasn't stated to do anything else - just tunneling his traffic for some unknown reason.
Op mentioned they use it while traveling. I use a VPN for, what are likely, similar reasons: I don’t trust the hotel networks or I want to access US region locked services while abroad.
> VPN providers are far more likely than AWS to do the kind of shady things that might matter to your relatives, like selling their personal data.
How do you know that AWS isn't spying on your systems? Are they transparent? Do AWS release detailed transparency reports on their servers? You are identified when you pay for AWS no?
I'd rather trust a specialist privacy VPN provider like Mullvad, than me rolling my own VPN on a provider that isn't even transparent and that is hard to use for consumers other than myself.
There's an internet provider (usually unknown / changing) behind every VPN provider. Whichever VPN provider you use, you may be implicitly trusting any of the good provider at any point in time.
There's a huge difference between being mixed into a shared pool of IPs where the internet pipe doesn't know who is who, and having your own server with a unique static IP that shows up both as your VPN server and the source of the outgoing connections.
> It is true that for updating WG you need to first disable the on-demand setting (probably only on Big Sur).
Which means shutting down the VPN, and exposing your hardware serial (the MAS app transmits this to Apple, along with your Apple ID) and true IP (which is equivalent to your city-level location) to Apple.
Transmitting your hardware serial to Apple along with your direct IP permits Apple and anyone with access to Apple's databases/logs a record of your travel history, because IPs are city-level geolocation.
Macs and iPhones also maintain a persistent connection to the Apple push notification service with a TLS client certificate obtained via registering with the hardware serial.
Just because you personally are okay with Apple and, by extension, the US military having your travel history doesn't mean that there's no problem with it.
To make the WireGuard windows app better (for non-admin users) you need to make your user(s) a member of the "Network Configuration Operators" group.
This allows you enable/disable (or choose if you have multiple) the VPN without needing to be a member of the Administrators group. You also need to add a line to the registry.
But yeah Apple doesn't make it any easier with vpns on big Sur, they have to use a new type e of extension now and they exclude their own services automatically.
Not something that seems related to these issues but it make macOS one again less interesting for me as daily driver
> and they exclude their own services automatically.
Unless you have information otherwise, I don't think that the whitelist applied to the filtering features used by Little Snitch et al also applies to VPNs.
Wireguard can only be installed via the Mac App Store, which, upon opening, transmits your permanent/unchangeable hardware serial number and Apple ID (required to download even free apps), which is linked to your phone number, to Apple, thus deanonymizing your VPN's public IP.
I don't use the Mac App Store. I run my VPN on a second device, because I no longer find the macOS to sufficiently preserve my privacy.
It's insane to me that Apple thinks it's okay to demand hardware serial number, name, street address, email, and phone number to download free privacy apps. An organization that had privacy as a value simply would not do that.
Apple has banned apps that want to use the NetworkExtension API from being self-signed, OR by being Apple-approved-developer signed and distributed outside of the App Store. You can download the windows Wireguard client from the Wireguard website, but not the mac one.
They even recently censored the donations link in the Wireguard mac client, because App Store.
The GL.iNet MNG-300v2 "Mango" is tiny and has built-in WireGuard support, and you can even set it up to switch WG on and off using the hardware switch:
If self and Apple-approved developer signing is not allowed, how do developers test their apps that use those APIs?
I don't know a lot about how Mac apps work, but I've heard somewhere that you have to sign all apps to build and install on any device.
That uses a different API that is widely assumed will be removed soon in a future macOS, and as such nobody wants to rely on it or build around it. It also requires root. It is not used by the Wireguard GUI app in the Mac App Store (MAS).
The wireguard-app-from-wireguard is only distributed via MAS, and you cannot build that GUI version that they distribute via MAS yourself, because that version uses the NetworkExtension API and that only works with the appropriate signed entitlement from Apple, which as of very recently didn't get issued outside of MAS apps.
What’s the point of ranting on your blog about a free and open source app that is quite new as well? At least raise a bug if you’re not willing to put in any effort to help.
It’s people like this that make it so hard to stay motivated to do any kind of open source work. Choosing beggars.
Does Donenfeld vouch for Tunsafe? I'd be reluctant to use a WireGuard client he didn't endorse, if only because I've been on the sidelines in conversations about VPN client software vulnerabilities and I know he's careful about this stuff (Donenfeld's background is in vuln research). There is more to get right than just the protocol.
I don't think he does, Tunsafe implements Wireguard, but it hasn't been updated for maybe 2 years now. Still, the UI is so much nicer than the Wireguard one
If the UI is more important to you than the security of your VPN, by all means but I think for most uses this is questionable advice. TunSafe development has been dormant for years, the official WireGuard client fixed one of its bigger Windows UI quirks just recently.
I totally understand why the Tailscale folks do it this way, but I don't really want to link my Google or MS accounts to my private VPN. The product looks fantastic though!!
I’m still sad about the state of WireGuard for average consumers. The protocol and the underlying tools are a simple and nice in a UNIX-like way, but for average people, it’s a wash. WireGuard would benefit greatly from a set of robust, easy to understand clients.
The current state of the world, where many VPN providers ship questionable apps of varying quality, is just sad for a solution that claims to prioritize security and privacy. The WireGuard app is somewhat useable, but it is by no means “easy to setup” unless you’re already familiar with how WireGuard works.
I found the Android client very easy to use. You can import a config file or scan a QR code to setup a profile. If you know what you are doing, you can setup it up manually.
Compared to the Cisco client we use for work, wireguard seemed better in every way.
WireGuard works perfectly on my Windows box for like half a year now. Standalone installation, no WinStore, or how is this thing by Microsoft called. It asked for auto-update 2 or 3 times since install and did it with no effort.
I became interested in how exactly it works and found an original code repo. It turned out that a delay between repo tag push and auto-update notification was about 15 minutes. This includes CI/CD pipeline time!
While it may be good from an encryption and basic security configuration perspective I find wireguard lacking from a networking and administration perspective.
Networking wise it implements a point to multipoint model which is just awful to deal with. I had hoped that moving on from frame relay and ATM had killed this model but wireguard brings it right back. Then you also have to deal with complications of wireguard interfaces always being up. The two combined means doing anything but the most basic setups means more complicationd with more chance for incorrect configuration than an ipsec or openvpn alternative.
Then there is the whole troubleshooting problem. When it doesn't work wireguard provides much less information to troubleshoot the issue than ipsec and openvpn.
Also there is the irritating lines of code comparison vs ipsec and openvpn when for the most part it is comparing apples to oranges since wireguard doesn't include many of the features of either which are required for an enterprise site to site or road warrior VPN solution. Once the solutions are in place to provide comparable functionality the attack surface is likely to be pretty comparable.
I've done a lot of professional work over the past few months† with WireGuard and can't think of a piece of information I've ever needed to troubleshoot it that it doesn't provide. You know about `dynamic_debug`, right?
There's also just not that much to debug! You've got keys, allowed IP lists, and endpoint addresses. There aren't a lot of other knobs to turn!
I think a thing that gets people into trouble with WireGuard is not understanding how modest its design is. The goal of WireGuard is to drop into the networking stack as just another interface. It doesn't intend to implement an entire new networking model on top of itself. My experience has generally been, if it's straightforward to express in the Linux networking model, it's straightforward with WireGuard.
I think this is a very good thing. I really don't want to have to think about what the OpenVPN developers believe about networking in general. I want to bring up secure transports and route packets over them the way I'd route over any other tunnel I want orthogonal, predictable interfaces that I (or Tailscale, or whatever) can build more complicated things on top of.
wireguard interfaces aren't point to point. Point to point would be much better than the point to multipoint interface model wireguard has chosen.
Wireguard claims separation of concerns but then sticks itself in the routing and packet filtering process instead of leaving those wholly to the existing established solutions.
Could you elaborate on how these issues and limitations you mention can manifest in practice? I’ve set up a couple of different topologies and haven’t felt limited yet.
Though troubleshooting packet loss is not fun and I haven’t been able to figure out how to avoid that and fragmentation, but I believe that’s more due to me than WG itself.
not op but one issue i have with it is that it ignores the routing table as soon the packet hits the interface. what i mean is if i tell the linux network stack to route packets "via" some address (which normally would involve arp) this configuration is completely ignored and the packet gets routed to whatever endpoint has the destination address as (confusingly named) AllowedIP address set. I expected it to do the lookup based on that via address and was trying to figure out what went wrong way too long. I think it would be kinda trivial to do this as i expected it after some minor research but that also led me to think it is supposed to be this way for some reason or another.
Yes, that's the normal behavior. If you have 172.16.10.0/24 that you are accessing via a wg peer at 172.16.1.10, then that peer needs to have both the 172.16.1.10/32 and the 172.16.10.0/24 in that peers allowedips. Then you can set a kernel route of 172.16.10.0/24 via 172.16.1.10 an the routing should work correctly.
no, the via part is just not considered. it does not make much sense to try though as it is impossible to have multiple peers with the same AllowedIPs addresses set. if it would honor the via address and allow me to configure multiple peers with the same AllowedIPs setting some dynamic routing could be made possible but it is not. However, i do configure it like you described just for consistency reasons when looking at the routing tables.
i.e. i could have peer A at 172.16.1.1 and peer B at 172.16.2.1. peer A would have AllowedIPs=172.16.1.1/32,172.16.0.0/24 and peer B would have AllowedIPs=172.16.2.1/32,172.16.0.0/24 and i could decide which peer gets traffic for 172.16.0.0/24 using the routing table by setting the via address to either 172.16.1.1 or 172.16.2.1 respectively. however, as stated this is not even allowed as only one peer would be able to have that subnet in its AllowedIPs setting present.
Ahh. If you are using wg-quick, the the script automatically adds interface level routes to the routing table that would override any manual static routes. You could add a Table=off flag to the wg interface config, and then you won't have the automatically generated route table entries based on the AllowedIPs flags, and your manual routes will be respected.
i do not. i manually manage these routes all by myself using systemd-networkd... these routes are respected but the via address is ignored nonetheless. to repeat myself, the via part of the route is not considered; i even double checked this by reading the code and furthermore did a PoC if it could be done. as soon as the route hits the interface the packets get routed according to the AllowedIPs setting regardless of any via address set on that route. If you are inclined enough to do so you can try it yourself. set it to a non existing address and you will see it will be routed regardless... or even set it to the address of an existing peer that has it set in its AllowedIPs setting and you will notice the peer that has the packets destination set as AllowedIPs setting will get the packets. which makes some sense as return traffic would only be allowed to come from that peer anyhow. i.e. for incoming packets the routing table is not even considered at all (analog to reverse path filtering).
Not OP, but I've seen one small issue with using WireGuard on GCP VMs — you must limit MTU to 1380 or it starts silently dropping some packets and leaves you wondering why some HTTPS sites refuse to load (I thought I set up a VPN to avoid censorship? why the hell am I still having the same issues?) Probably an obvious thing for a networking expert, but it took me a few minutes to figure out what's going on.
Kind of an aside, but the network engineers I've worked with would mockingly blame MTU every time there was a connectivity problem, because it so rarely turns out that MTU is the issue. (I trust in this case you are correct though.)
Had exactly the same experience. Definitely annoying, but more that anything else, I’m impressed that Rachel was able to turn it into cogent blog post.
A friend recently attempted to chat with me over XMPP on macOS. The result was a nightmare of trying different out of date and poorly supported mac clients. They seemed quite used to the process. The logical choice for desktop (Gajim) did not have an app available. The MacPort is wildly out of date. Which is too bad because Gajim supports macOS. It seems that no one can be bothered to package it.
It's like everyone has abandoned MacOS but are too polite to admit it...
For the record, Beagle IM and Monal are both in the macOS app store, open-source and actively maintained XMPP clients.
I generally agree with your observation though. I'm not really a macOS developer, but from the sidelines it appears it has become increasingly difficult to develop and ship open software for both Apple operating systems. See for example this discussion from a few months ago ("Can't you just right-click?"): https://news.ycombinator.com/item?id=24217116
Gajim specifically has support for macOS and is well maintained. It is available on pretty much every desktop OS. No one has even bothered to package it for macOS even though it would be quite easy to do so. So it would have to be the case that macOS users in particular have abandoned XMPP.
Part of the point of running WireGuard is never having to expose IPSEC code to your adversaries, so I don't really see the appeal of something that sets up both WireGuard and a bunch of IKE stuff.
ZeroTier is so much better than WireGuard. I literally spend 2 weeks futzing about with a WireGuard config and was able to set up a VPN between my homelab and my new apartment in less than 15 minutes with ZT.
Day and night difference in quality and ease of use.
I've got Tailscale setup. It uses Wireguard under the hood, so I don't have to worry about the security of the protocol, just whether I trust the company providing the management. Took just as much time to setup as you did with ZeroTier.
This is not unique to Wireguard. I’ve had this happen with the Lockdown app too. This is an Apple problem. Apple should notify you that the VPN app needs to close in order to upgrade then offer you a simple way of doing that.
> I don't know exactly, and I don't really care.
This about sums it up. This is a rant and it’s difficult not to just close tab half way through.