This post is the fourth in a series; see here for part 1, here for part 2 and here for part 3.
Wireguard is relatively new; it is technically a VPN, which purports to combine the ease of SSH with state-of-the-art cryptography. It runs natively (no virtual machine required) on linux as the server end, and has clients (the computer you connect from) for linux, Windows, iOS, Android and maybe even a dead badger. Full disclosure: this will be my first time using wireguard.
Since Wireguard has no native windows version for the server, I found a program called Wiresock that was compiled and configured specifically for Windows Server. Great! However, the installation of it hangs on the final step, which is the “Configuring the Firewall Rule” step. I actually let it run overnight just to make sure it wouldn’t eventually move forward, which it didn’t. I also ran it as administrator, and got the same result.
Instead, I decided to use our friend, the Windows-Subsystem-for-Linux (WSL), with the plan to eventually install Wireguard after setting up WSL. Unfortunately, this great feature is not available for Server 2016, only Server 2019 and onward. So, I tried to use Hyper-V, Windows’ native virtualization host, but for some bizarre reason, it appears virtualization has been disabled on this particular server.
A bit of history here: I didn’t originally set the Windows Server 2016 computer up. It is running through a remote connection to a cloud server, which means the Server 2016 is almost certainly a virtual machine itself. This should not cause a problem, however, unless the virtualization-within-virtualization was deliberately turned off, most likely by the cloud administrator…who I was unable to contact.
Since Microsoft’s built-in Hyper-V virtualization didn’t work, I switched to using an open source virtualization host, called Virtualbox. When I tried to install it, it said it needed several Microsoft C++ modules, so I had to download and install those…then I was able to successfully install Virtualbox! When I ran Virtualbox, it produced an error, basically indicating that virtualization wasn’t enabled. I looked up the error, ran through a few of the suggested fixes, but they didn’t make any difference.
It appears that, after all, virtualization at this level was disabled at a level higher than the one I had access to, and there’s no viable method of getting around it. To put it in more precise terms, there isn’t any method of getting around it that is worth the time & effort it would take to do so.
I present this story, not as a harrowing glimpse into the life of an IT support administrator, but rather to illustrate 2 important lessons I’m always struggling to keep in mind:
- I generally don’t want to commit myself exclusively to one path to a solution. I should always be performing a cost-benefit analysis, and always figure in the value of my time when trying to solve a problem.
2. You must know when to cut your losses. There was no need to commit too much time to this method, as I already had a viable solution for the problem. Speaking of…
