WireGuard: great protocol, but skip the Mac app
WireGuard is an interesting conundrum. On the one hand, it's a solid transport, and just sits there and runs and runs. The 'plumbing' side of things has never been a problem. The 'porcelain', that is, the user interface and things that humans actually interact with, however, is another story entirely.
I got excited some months back when WireGuard got an app in the Mac app store. This way I could just load that on, configure it, and I'd be off to the races. I figured I'd get the occasional update and that would keep everything cozily secure.
While the actual connections have yet to fail me, the apps have multiple times. This started about a week ago. Version 1.0.10 for the Mac came out, and I foolishly decided to ask it to upgrade, because it kept showing up in the list of stuff that wanted to be handled. I clicked the [upgrade] button in the App Store, and it did the little circle with a growing arc that fills in... and then promptly went back to saying [upgrade]. It *should* have said [open] at that point, reflecting the completed upgrade, but it did not.
Then I remembered, having seen this on a family member's machine when I was pressed into doing tech support for it: WireGuard won't upgrade itself if it's still running. It also won't (or can't?) stop itself to do this. You have to manually deactivate the tunnel. Now, if you're the sort who keeps a tunnel nailed up with the on-demand feature for whatever reason, this is going to be a problem.
The problem is that clicking [deactivate] means very little when the on-demand mode is enabled. It will totally stop the tunnel, and then will happily start it right back up a second later. To stop this silliness, you have to go into the config editor, type in the admin password, and uncheck the on-demand boxes. Only then can you shut it down, and then the upgrade will probably proceed.
When I did this and got 1.0.10 on the 16th, the upgraded version would just try a connection, sit there for a bit, then go back to disconnected. It never got connected, and it never said anything about why. Digging around turned up a log window (a modal that blocks all other things in the app) which said something about a timeout. It later turned out that something or other happened upstream, and now they treated timeouts as failures, or something, I don't know exactly, and I don't really care.
Just the way it failed told me something was up with the overall model here. It feels like the UI is poking at the "thing doing the actual work" with very long and wobbly sticks. It's doing this in a dimly-lit room with oversized gloves zip-tied to its hands, and its glasses are smeared with filth. In short, it's not in control of the situation, not really.
It's hard to explain if you haven't experienced this before. But trust me, once you've encountered it, you'll soon recognize the laggy controls, the things which seem at odds with what's going on, and a general lack of a grasp on the situation. It's just something with UIs that you start noticing.
At that point, I forcibly deleted the app from the machine and installed it from Macports. Given that I already had a High Sierra Mac for which there is no app store build, I knew what to do. It's the same old "mkdir blah, create keys, create conf, write start/stop scripts" thing as any other Unix box, but you have to do an extra helper script and a plist file to make the Mac's launchd process keep it running.
That was what happened last week on one machine. Then, yesterday, I upgraded my MacBook Air to Big Sur to work on my ongoing Thunderbolt issues (update coming on that soon), and sure enough, now WireGuard on here wanted to be upgraded - to 1.0.11. (I had left THIS machine at 1.0.9 after the hell of 1.0.10).
I guess I was feeling sufficiently bored and stupid and so I clicked the [upgrade] button. It did the circle-filling-arc thing... and went right back to [upgrade]. Oh, yeah, I have to stop it first. Which means turning off the on-demand. Which means editing the config.
So, I went into the app, hit the edit button, and ... nothing happened.
Click, click, click. Nothing. No error, just no action... and nothing in the log to suggest why.
Remember what I said about the app not really being in touch with what was going on? This is what I meant.
I decided it was time to give this thing the app death penalty and put *this* machine on the Macports solution, too. I tried using the "export config as .zip file" thing so I could at least save my keys and whatnot, but nope, that didn't work either. I wound up having to just write it off, and accepted that I would have to build a fresh config for the stuff I had been doing with it, and had to rewrite the other end(s) too.
But, it wasn't done with me yet. You can't even uninstall it (throwing it in the trash from the Applications folder) because the extension is running. You have to pop open a root shell and kill -9 that extension and then quickly trash it before it can respawn. Only then will it truly be gone.
At this point, I am now app-less on my personal Macs, and you better believe I am going to do this approach on the family machines as I encounter them. (It's a little dicey doing this remotely, since nobody's hanging out with anyone else this year, obviously.)
What about the problems? Well, it's free. They owe me nothing. But, you should still be aware what you are getting into when you choose to run it this way. That's why I wrote this post: to serve as a warning to others. Let my frustration save you the same in the future.
When it comes to WireGuard, just stick with the tried and true low-level Unix approach, even on your Macs. Your sanity will thank you.
I just hope the iOS version never flips out on me.