WireGuard for Windows 0.3.1 is the release you’ve been waiting for

[Karlston]

WireGuard for Windows 0.3.1 is the release you’ve been waiting for

Unprivileged users can start and stop WireGuard tunnels via the UI now.

Enlarge / I heroically resisted the urge to create a "WireGuard for Workgroups 0.3.1" image for this piece.

Jim Salter

13 with 13 posters participating, including story author

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.

Installation

Enlarge / Existing WireGuard users will be prompted with obvious UI hints to download and install the new version, directly from within the application itself.

Jim Salter

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

First image of article image gallery. Please visit the source link to see all images.

 

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 HKLM\SOFTWARE\WireGuard, then create a DWORD at HKLM\SOFTWARE\WireGuard\LimitedOperatorUI and set it to 1. (Don't be confused at the lack of HKLM\SOFTWARE\WireGuard 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 DWORD at HKLM\Software\WireGuard\MultipleSimultaneousTunnels 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

Enlarge / WireGuard used to store its configs under the user directory. Windows 10 really didn't like that, so it's (properly, in our opinion) been moved to a global configuration directory at C:\Program Files\WireGuard\Data\Configurations.

Jim Salter

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 Files\WireGuard\Data\Configurations—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

First image of article image gallery. Please visit the source link to see all images.

 

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.

 

Using the wg command, Administrators can:

• generate arbitrary private and public keys (wg genkey and wg pubkey)
• view the configuration of running tunnels (wg showconf)
• manipulate running tunnel configurations directly (wg set and wg setconf)
• view information on current interfaces and tunnels (wg show)

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 PreUp, PostUp, PreDown and 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:

HKLM\Software\WireGuard\DangerousScriptExecution

When this key is set to DWORD(1), the tunnel service will execute the commands specified in the PreUp, PostUp, PreDown, and PostDown options 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_NAME to 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

Enlarge / The config I use for my phone routes all traffic over the tunnel, using the /0 route seen on the left. Unchecking the "Block untunneled traffic" box automatically splits it into two /1 routes, as seen on the right.

Jim Salter

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: 0.0.0.0/1 and 128.0.0.0/1 to cover the entire IPv4 space, and ::/1 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.

 

 

WireGuard for Windows 0.3.1 is the release you’ve been waiting for

 

(To view the article's image galleries, please visit the above link)