WireGuard-Client unter Windows

Mit WireGuard steht eine schlanke und zugleich moderne wie auch sehr performante VPN-Lösung bereit, die mittlerweile in immer mehr Routern und anderen Produkten und Plattformen Einzug hält.

Ursprünglich gab es nur einen Client (wie auch Server) für Linux, im Laufe der vergleichsweise jungen Geschichte kamen Implementierungen und Clients sowie Apps für weitere Betriebssysteme hinzu.

Seit einiger Zeit gibt es einen offiziellen WireGuard-Client für Windows, dieser bietet neben einer grafischen Oberfläche für das Erstellen, Importieren oder auch Exportieren von Tunneln zudem eine Steuerung via CLI an. In diesem Beitrag geht es um verschiedene Aspekte der Nutzung des Clients unter Windows und beschäftigt sich unter anderem mit unterschiedlichen Nutzungsszenarien.

Persönliche Vorab-Bemerkung: Im Laufe der folgenden Zeilen ziehe ich die meisten Vergleiche von WireGuard zu OpenVPN, da ich dieses seit vielen Jahren in unterschiedlichen Szenarien verwende. Mit IPsec habe ich, abgesehen von ganz wenigen FRITZ!Boxen, bereits seit sehr langer Zeit nichts mehr zu tun.

Nutzung der GUI wenn der Benutzer administrative Rechte hat

Der WireGuard-Client funktioniert am Besten, wenn der ausführende Benutzer administrative Rechte hat, denn die zugrundeliegenden ausführbaren Dateien müssen Dienste anlegen, starten, beenden und löschen dürfen, ebenso wie das Setzen von Routen. Abgesehen davon ist die grafische Oberfläche simple und funktional:

Nutzung der GUI wenn der Benutzer keine administrative Rechte hat (Non-Admin)

Der offizielle Weg als normaler Benutzer WireGuard unter Windows nutzen zu können besteht darin das man in der Registry zunächst eine Änderung vornimmt. Der nachfolgende Einzeiler mit erhöhten Rechten ausgeführt erledigt die Aufgabe am einfachsten:

reg add HKLM\Software\WireGuard /v LimitedOperatorUI /t REG_DWORD /d 1 /f

Zusätzlich muss der Benutzer Mitglied in der Gruppe “Netzwerkkonfigurations-Operatoren” sein.

Quelle: Registry Keys for Admins

Grundsätzlich muss allerdings immer vom Administrator-Desktop (runas und Co. reicht nicht aus!) die Konfiguration angelegt oder importiert werden, erst dann kann der Benutzer den oder die Tunnel starten oder stoppen.

Persönlicher Erfahrungswert: Auf drei verschiedenen Windows-Systemen hatte ich mit der Nutzung von WireGuard als Non-Admin keinen wirklichen Erfolg. Die GUI öffnete sich immer erst dann, wenn man zuvor als Administrator angemeldet war und dort zuerst die GUI gestartet hatte. Wirklich praktikabel war und ist das nicht, daher wurden weitere Wege gesucht, dazu weiter unten mehr.

Wer sich noch an frühere Zeiten mit dem OpenVPN-Client unter Windows erinnern kann, dürfte ein gewisses Déjà-vu erleben. In dessen Anfangstagen war lange Zeit eine Nutzung ohne administrative Rechte ebenfalls nicht (so einfach) möglich, dort “scheiterte” es allerdings meist nur am Setzen der Route.

Steuerung via CLI

Neben der grafischen Oberfläche kann man mittels der “wg.exe” und “wireguard.exe” in der Eingabeaufforderung oder mittels Skript(e) WireGuard-Tunnel anlegen, ändern, starten, stoppen und entfernen. Dies bietet einige Möglichkeiten und ermöglicht zudem die Integration in automatisierte Abläufe oder in Admin-Werkzeugen. Die “wg.exe” dient primär dem Erzeugen der notwendigen Schlüssel und zum einsehen und ändern einer bestehenden Verbindung:

C:\Program Files\WireGuard>wg --help
Usage: wg <cmd> [<args>]

Available subcommands:
show: Shows the current configuration and device information
showconf: Shows the current configuration of a given WireGuard interface, for use with `setconf'
set: Change the current configuration, add peers, remove peers, or change peers
setconf: Applies a configuration file to a WireGuard interface
addconf: Appends a configuration file to a WireGuard interface
syncconf: Synchronizes a configuration file to a WireGuard interface
genkey: Generates a new private key and writes it to stdout
genpsk: Generates a new preshared key and writes it to stdout
pubkey: Reads a private key from stdin and writes a public key to stdout
You may pass `--help' to any of these subcommands to view usage.

Die “wireguard.exe” hingegen ist für die Tunnel-Dienste verantwortlich:

C:\Program Files\WireGuard>wireguard.exe --help

Kurzum, ein

"C:\Program Files\WireGuard\wireguard.exe" /installtunnelservice <Konfigurationsdatei>

installiert einen neuen Dienst mit dem Namen “WireGuard Tunnel: <Name der Konfigurationsdatei OHNE .conf>” und startet diesen.

Allerdings sind auch hierbei die Berechtigungen zu beachten! Als Workaround(s) kann man die “wireguard.exe” über eine Aufgabe mit höheren Rechten ausführen lassen oder das Skript als Dienst anlegen und steuern. Wie dies grundsätzlich geht, ist in folgenden Beiträgen beschrieben:

Windows: Aufgaben durch andere Benutzer ausführen lassen

Windows: Ein Skript oder eine Anwendung als Dienst ausführen

Tests haben gezeigt, das der Weg über einen eigenen Dienst gut funktioniert, aber dann benötigt der Benutzer die Berechtigung Dienste starten und beenden zu dürfen. Mitunter einfacher erscheint die Nutzung einer Aufgabe, da diese vom einfachen Benutzer z.B. mittels

schtasks /run /tn "WireGuard"

ausgeführt werden kann.

Nachteil: Via Aufgabe oder als Dienst gestartet, werden der oder die Tunnel nicht in der GUI angezeigt. Da die GUI allerdings als normaler Benutzer meiner Erfahrung nach ohnehin nicht richtig funktioniert, kann und muss man dies an dieser Stelle vernachlässigen.

Ausblick: Ich arbeite an einem Skript und Tool, das nach dem Start des Tunnels signalisiert, das eine Verbindung besteht.

Ausführen von Befehlen und Skripten

WireGuard bietet die Möglichkeit, Befehle und Skripte bei verschiedenen Verbindungs-Stati auszuführen. Damit dies überhaupt möglich ist, muss man dies zunächst in einer Eingabeaufforderung mit erhöhten Rechten ermöglichen:

reg add HKLM\Software\WireGuard /v DangerousScriptExecution /t REG_DWORD /d 1 /f

Nun kann man in der Konfigurationsdatei im Abschnitt “[Interface]” angeben, das z.B. vor der nach dem Verbindungsaufbau etwas ausgeführt werden soll:

PreUp = <Befehl oder Skript>
PostUp = <Befehl oder Skript>

Ein ganz großes ABER gibt es an dieser Stelle: Diese Befehle werden mit SYSTEM-Rechten ausgeführt, das ist zwar am Beispiel von Split Tunneling für den Punkt DNS hilfreich (dazu gleich mehr), allerdings unbrauchbar wenn z.B. ein Netzlaufwerk nach dem Verbindungsaufbau verbunden werden soll.

Soviel zum Client an sich. Nachfolgend verschiedene typische Roadwarrior-VPN-Szenarien und wie man diese speziell mit WireGuard unter Windows umsetzen kann.

Alles durch den Tunnel (DNS + Redirect-Gateway)

Um grundsätzlich jeden Datenverkehr umzuleiten, muss man lediglich zwei Zeilen in der Konfigurationsdatei auf dem WireGuard-Client anpassen:

Im Abschnitt “[Interface]”:

DNS = <IP-Adresse des DNS-Servers>

Im Abschnitt “[Peer]”:

AllowedIPs = 0.0.0.0/0

Auf der Gegenseite, gemeint ist der beim WireGuard-Server, muss die Firewall den Datenverkehr natürlich durchlassen und routen können. Am WireGuard-Server ist im Vergleich zum OpenVPN-Server diesbezüglich nichts spezielles zu konfigurieren.

Split Tunneling (Routing)

Beim Split Tunneling geht es darum, nur bestimmten Datenverkehr in den Tunnel zu leiten. Das bekannteste Beispiel ist der Zugriff auf das Firmennetzwerk, mehr aber auch nicht. Damit nun das oder die IP-Netz(e) der Gegenseite erreicht werden können, muss lediglich folgen Zeile angepasst werden:

Im Abschnitt “[Peer]”:

AllowedIPs = 192.168.175.0/24

Mehrere Netze können komma-getrennt angegeben werden:

AllowedIPs = 192.168.175.0/24, 192.168.2.0/24

Split Tunneling (DNS)

Das Thema “Split Tunneling” und DNS ist bei WireGuard leider recht kompliziert. Fügt man im “[Interface]”-Abschnitt der Konfigurationsdatei den DNS-Eintrag hinzu:

DNS = 192.168.175.1

werden alle DNS-Anfragen zu diesem Server umgeleitet! Versucht man nun beispielsweise mit

DNS = 192.168.175.1, domain.tld

ein verbindungsspezifische DNS-Suffix zu verwenden funktioniert es ebenfalls nicht. Das Suffix wird zwar gesetzt, aber offenbar greift es nicht. Abhilfe schafft die Funktion NRPT – Name Resolution Policy Table zu nutzen, die Microsoft mit DirectAccess eingeführt hat. Gefunden wurde dieser Lösungsansatz hier:

reox’s projects/ blog/ posts/ wireguard dns only for vpn

Kurzum, man aktiviert wie weiter oben beschrieben die Skript-Ausführung und fügt im Abschnitt “[Interface]” folgende Befehle hinzu:

PostUp = powershell -command "Add-DnsClientNrptRule -Namespace '<domain.tld>','.<domain.tld>' -NameServers '<IP-des-DNS-Servers>'"
PostDown = powershell -command "Get-DnsClientNrptRule | Where { $_.Namespace -match '.*\.domain\.tld' } | Remove-DnsClientNrptRule -force"

Diese müssen hinsichtlich “domain.tld” und IP des internen DNS-Servers angepasst werden. Vor dem Tunnelaufbau wird die konfigurierte DNS-Domäne und deren DNS-Server bekannt gemacht und nach dem Tunnelabbau werden die Daten wieder gelöscht.

In der PowerShell (mit erhöhten Rechten) kann man mit

Get-DnsClientNrptRule

während der Tunnel besteht prüfen, ob die Richtlinie konfiguriert ist.

Das funktioniert, aber wirkt nicht auf alle Befehle. nslookup kann einen FQDN so nicht auflösen. Ein Ping auf den FQDN wiederum soll dem Hörensagen nach funktionieren, in meinen Tests kam allerdings immer ein Fehler von der Transfer-Netz-Adresse des WireGuard-Server zurück. Alternativ kann man auf die PowerShell zurückgreifen:

Resolve-DnsName <FQDN, domain.tld oder IP>

Nur Host- bzw. Computernamen funktioniert nicht, hingegen klappen aufrufe von FQDNs und URLs im Explorer und Browser.

Weiteres

Neutral: Im Gegensatz zu OpenVPN kann man bei WireGuard keine Einstellungen vom Server zum Client übertragen (pushen), d.h. eine zentrale Verwaltung ist nicht möglich und man muss seine Konfigurationsdatei für die Clients entsprechend ordentlich planen und verteilen. Man arbeitet (imho) am besten mit einer Vorlage die nur noch personalisiert werden muss.

Der Speicherort einer in der GUI importierten oder manuell angelegten Konfiguration lautet:

C:\Program Files\WireGuard\Data\Configurations

Die dortigen Konfigurationsdateien sind verschlüsselt. Kopiert man dort eine unverschlüsselte Konfigurationsdatei hinein, wird diese ebenfalls verschlüsselt!

Mehrere gleichzeitige Tunnel sind möglich, nachdem man in der Registry zuvor “MultipleSimultaneousTunnels” (siehe Quellen) setzt.

Fazit

Wer viel mit unterschiedlichen VPN-Verbindungen arbeitet, wird die CLI und die damit einhergehenden Automatisierungsmöglichkeiten zu schätzen Wissen. Mit ihrer Hilfe konnte ich WireGuard beispielsweise in mRemoteNG integrieren oder eine einfache Einwahl für einen Kunden realisieren so das man auf Mausklick eine Verbindung aufbauen oder trennen.

Der WireGuard-Client unter Windows ist nicht schlecht, aber es gibt noch Luft nach oben.

Mehrere Tunnel gleichzeitig, ohne das wie bei OpenVPN mehreren tun- oder tap-Interfaces benötigt werden, sind möglich. Hier ist allerdings, wie bei jeder anderen VPN-Lösung auch, das Routing zu beachten. Gemeint ist, das auf beiden Seiten des Tunnels das IP-Netz eindeutig sein sollte.

Quellen

Microsoft – Docs – DnsClient

GitHub – WireGuard/wireguard-windows

rair.dev – WireGuard Windows – Multiple Simultaneous Tunnels

2 Kommentare

  • Hallo,
    wie schaffe ich es, das der Wireguard Windows Client sich automatisch (dynDNS) aktualisiert?

    Beste Grüße
    Werner Danisch

  • Aus der Frage leite ich mal ab, das der Wireguard-Server via DynDNS angebunden ist?
    Wenn dem so ist, ist die Frage, ob der Wireguard-Client bzw. das Betriebssystem oder der Route bzw. DNS-Server den DynDNS-Eintrag zwischenspeichert und für wie lange das passiert.
    Ein Versuch kann darin bestehen, unter Windows mit

    ipconfig /flushdns

    Den DNS-Cache zu löschen und dann erneut zu versuchen sich zu verbinden. Wenn das klappt ist es gut und man kann den Befehl als Skript dem Wireguard-Client mitgeben.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.