This Monday, WireGuard founder and lead developer Jason Donenfeld announced a new WireGuard release for the Windows platform. The release is something of a godsend for administrators hoping to implement WireGuard as a replacement for more traditional end-user VPNs in a business environment, adding several new features that will make their lives easier—or simply make its implementation possible, in environments where it otherwise would not.
If you haven’t heard about WireGuard yet, it’s a relatively new VPN protocol featuring advanced cryptography. It’s implemented from the ground up as an exercise in cleanly written, minimalist, maximally secure and performant code—and it succeeded at those goals well enough to get Linus Torvalds’ own rarely-seen stamp of approval.
Those who are already using WireGuard on Windows will receive an obvious in-app prompting to download and install the new version, which works swimmingly. New users can download WireGuard directly from its website.
The simple “Download Installer” button is aimed at Windows end users, and this probes the user’s system to determine which MSI installer to fetch and execute, based on the user’s system architecture. Sysadmin types may also browse the list of MSIs directly, for use with Active Directory Group Policy automated deployments.
WireGuard for Windows currently supports x86_64, x86 (32-bit), ARM, and ARM64 architectures.
Improved tunnel management for Windows users
Probably the most desperately-sought feature in WireGuard’s windows implementation is the ability for unprivileged users to activate and deactivate WireGuard tunnels via the app’s user interface. Until release 0.3.1, WireGuard has only allowed members of the Administrators group to open the UI, let alone do anything within it.
As of version 0.3.1, that limitation has finally been removed. Unprivileged users may be added to the Windows Builtin group “Network Configuration Operators”—and, once members of that group, if and only if the requisite registry key was added and DWORD value set, they can manage their own tunnel into the corporate LAN.
There’s one more step necessary to enable the limited UI—you need to open
regedit, create the key
HKLMSOFTWAREWireGuard, then create a DWORD at
HKLMSOFTWAREWireGuardLimitedOperatorUI and set it to
1. (Don’t be confused at the lack of
HKLMSOFTWAREWireGuard itself—you’ll need to create that, too.)
Otherwise-unprivileged users who’ve been allowed into the WireGuard club can see the tunnels available and start and stop those tunnels. They cannot see the public keys for the tunnels—and more importantly, they can neither add, remove, nor edit those tunnels.
Unprivileged users also cannot exit the WireGuard application itself—they can close the dialog just fine, but the “exit WireGuard” item is missing from the context menu in the system tray. This is because closing the WireGuard app from the system tray doesn’t just get rid of the icon, or even disable the WireGuard tunnel services—it actually uninstalls those services entirely. (The services are automatically reinstalled the next time an Administrator runs the WireGuard app.)
Also new to WireGuard for Windows 0.3.1, multiple tunnels can be simultaneously activated from the GUI. This feature is also registry-gated for now—to use it, you’ll need to create a
HKLMSoftwareWireGuardMultipleSimultaneousTunnels and set it to 1. Without creating and setting that
DWORD, WireGuard for Windows 0.3.1 continues to behave like earlier versions, and activating one tunnel from the GUI will automatically deactivate any others.
Global configuration directory, with automatic configuration file import
One of the minor annoyances we had in previous versions of WireGuard for Windows was the app’s insistence on being fed tunnels to import, rather than simply finding them in a directory—as OpenVPN does, and for that matter as WireGuard itself does on Linux or BSD operating systems.
Beginning with version 0.3.1, those who don’t want to use the clicky buttons to set up tunnels no longer need to. The app moved its own internal configuration store from a location within the user profile directories to
C:Program FilesWireGuardDataConfigurations—and it now automatically scans that folder for new
.conf files at startup, too.
The upshot here is that a configuration file, such as the
pixel2.conf configs I stole from my personal phone’s WireGuard profile:
# tunnel used on my Pixel2 phone [Interface] PrivateKey = sJPcq5V2p30RK/SSUIMtIA4TRsAHc/Apdo8x6gTL8EE= Address = 10.8.144.2/32 DNS = 10.8.144.1 [Peer] PublicKey = bVteNlvZZipqRr4xCRTEAz+D3CVS0lOS+RQzw8zB4DI= AllowedIPs = 0.0.0.0/0 Endpoint = honeypot.fbi.gov PersistentKeepAlive = 20
… can be dropped directly into the new configuration directory. WireGuard will then automatically detect the new .conf, import it and save it back out as an encrypted
.dpapi file as seen above. The
.dpapi file is itself encrypted and very unlikely to be useful to an attacker. This is assuming the attacker can even deal with the permissions—by default,
.dpapi files stored by WireGuard are owned by
SYSTEM, and even members of the
Administrators group can’t read them.
Side note: No, that’s not my real private key. That’s also not my cloud instance’s real public key—and while there is no active DNS record for honeypot.fbi.gov at press time, I still wouldn’t recommend poking it too hard.
Support for the wg command, as seen in Linux and BSD
WireGuard on Windows has traditionally had far more in common with the WireGuard mobile apps for Android and iOS than with the more robust, command-line driven applications on Linux and other Unix-like operating systems. That line begins to blur with release 0.3.1, as the full
wg command is made available to Administrators on the command line.
wg command, Administrators can:
- generate arbitrary private and public keys (
- view the configuration of running tunnels (
- manipulate running tunnel configurations directly (
- view information on current interfaces and tunnels (
Because these commands are meant for manipulating private keys and networking details, the new functionality is strictly limited to Administrators.
Note that while
wg is available, the limited-but-handy
wg-quick command is not available. There is, however, a somewhat-analogous
wireguard command, documented under Enterprise Usage in the WireGuard repo.
Pre- and post- execution hooks
Another previously *nix-only feature makes it down to Windows with version 0.3.1—the
PostDown scripting hook arguments in tunnel configuration files.
These hooks are exactly what they sound like—a way to require arbitrary code to be run before or after bringing a tunnel up or down. They’ve been available from the start in WireGuard on Linux or BSD operating systems, but they’ve been conspicuously absent from Windows until now.
I’ll let Donenfeld himself speak about why they’re still disabled by default, you will need to create a Registry key in order to use them, and from the sounds of it, he’d still really prefer you didn’t:
When this key is set to
DWORD(1), the tunnel service will execute the commands specified in the
PostDownoptions of a tunnel configuration. Note that this execution is done as the Local System user, which runs with the highest permissions on the operating system, and is therefore a real target of malware. Therefore, you should enable this option only with the utmost trepidation. Rather than use
%i, WireGuard for Windows instead sets the environment variable
WIREGUARD_TUNNEL_NAMEto the name of the tunnel when executing these scripts.
Let’s repeat that for the folks in the back—things automatically executed in the Pre/Post Up/Down hooks are executed as
Local System, and therefore make excellent malware targets. If you’ve enabled these arguments, you’ll need to exercise extreme caution when copying and pasting tunnel configurations you find on the internet.
Improved split-tunnel DNS handling
When WireGuard configs include a
DNS argument in an Interface stanza, WireGuard creates system firewall rules which prevent DNS queries to resolvers not listed in those stanzas. This prevents DNS “leaks,” a common privacy concern revolving around DNS resolution of private, tunnel-bound activities via public DNS resolvers.
This has presented problems for some split tunnel setups that depend on standard Windows multihomed DNS behavior. In order to resolve the conflict, WireGuard for Windows 0.3.1 only adds these firewall
deny rules if a
/0 subnet is in
AllowedIPs. Admins who need global routing across the WireGuard tunnel—but who also need working DNS resolution from servers not specified in the
DNS argument—can work around this by instead splitting the world into two subnets:
188.8.131.52/1 to cover the entire IPv4 space, and
8000::/1 for the IPv6 space.
Within the WireGuard for Windows UI, when the application detects a /0 route, it will also present a checkbox labeled “Block untunneled traffic (kill-switch)” inside the Edit tunnel dialog. Unchecking that box will automatically split the single /0 route into two /1 routes and clear the firewall rules preventing DNS checks. Checking it again will collapse the two /1s back into a single /0, and bring back the firewall deny rules.
If this doesn’t answer all your questions, we recommend searching for further answers in WireGuard’s netquirks document for Windows users.