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
Quelle: Registry Keys for Admins
Zusätzlich muss der Benutzer Mitglied in der Gruppe “Netzwerkkonfigurations-Operatoren” sein und einmalig muss WireGuard vom normalen Benutzer aus mit erhöhten Rechten, d.h. als Administrator, gestartet werden. Offenbar werden irgendwelche Änderungen irgendwo gespeichert und erst dann kann der normale Benutzer zukünftig WireGuard starten und verwenden.
Vielen Dank an Christian Riegert für den Hinweis mit dem “einmalig als Admin ausführen”.
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.
Führt man den Schritt mit dem einmaligen Starten von WireGuard als Administrator vom normalen Benutzer aus nicht aus geschieht folgendes bzw. funktioniert es nicht:
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.
Wenn die GUI nicht startet
Lässt sich die GUI nicht aufrufen, da beispielsweise eine Meldung erscheint das der Dienst bereits laufen würde, aber kein Symbol im Infobereich (Tray) vorhanden ist muss in der Regel der Dienst
WireGuard Manager (Dienstname: WireGuardManager)
neu gestartet werden. Auf einem neuen Notebook hatte ich dieses Problem reproduzierbar nach jedem Neustart. Abhilfe kann schaffen, den Starttyp des Dienstes auf “Automatisch (Verzögerter Start)” zu stellen.
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
GitHub – WireGuard/wireguard-windows
rair.dev – WireGuard Windows – Multiple Simultaneous Tunnels
Update 09.02.2023
Den Abschnitt “Wenn die GUI nicht startet” hinzugefügt.
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
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 /flushdnsDen 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.
Hallo Andy, lieben Dank für den Blog. Ich will wireguard im Unternehmensumfeld einsetzen und habe es nun mal getestet. Mit entsetzen habe ich festgestellt, dass ich im Windows Client mir jederzeit die komplette Konfiguration anzeigen bzw. ändern kann.
Wenn also der Nutzer die Konfiguration unter Windows im Client ausließt, kann er diese überall neu einlesen und hat ebenfalls Zugriff auf das Netzwerk. Das kann doch so nicht sein, oder?
Eigentlich sollte doch nach Einrichtung die 3 Keys verschlüsselt da liegen bzw. nur als * sichtbar sein.
Grüße
Christian
Wie kann die Konfiguration im Windows Client sicher geschützt werden? Ein Weitergabe ausgeschlossen werden?
Hallo Christian,
die vollständige Konfiguration ist nur sichtbar, sofern der Benutzer Admin-Rechte hat, der Otto-Normal-User kann Tunnel nur auf- bzw. abbauen und sieht von der Konfiguration nichts.
Der Umstand das Benutzer unter Umständen die gesamte Konfiguration sehen bzw. kopieren können ist nicht auf WireGuard beschränkt, bei OpenVPN und IPsec ist das je nach Client-Software ebenfalls (leider) möglich.
Wenn man die GUI von WireGuard wegen der Admin-Rechte-/Konfigurations-Thematik nicht nutzen möchte/kann oder soll, dann besteht ein Workaround darin, die Konfigurationsdatei in einen Ordner zu kopieren und mittels NTFS-Rechte den Zugriff darauf einzuschränken, das nur der Dienst Zugriff darauf hat.
Den WireGuard-Tunnel kann man wie im Beitrag beschrieben mit
"C:Program FilesWireGuardwireguard.exe" /installtunnelserviceinstalliert und mit
"C:Program FilesWireGuardwireguard.exe" /uninstalltunnelservicedeinstallieren. Der Dienst muss nur einmalig installiert werden.
Ob man den WireGuard-Dienst dann immer auf automatisch lässt oder den Dienst nur bei Bedarf startet bzw. starten lässt ist halt die Frage, wie es letztlich sein soll.
Erfahrungsgemäß ist das Kunden-abhängig.
Wie soll es denn bei dir/euch sein? Womöglich habe ich dazu schon eine Lösung oder kann eine entsprechend skizzieren oder entwickeln.
Beste Grüße,
Andy
Hallo Andy, lieben Dank für die Antwort. Sicherlich im Unternehmensumfeld haben die Nutzer keine Adminrechte. Mir ging es jedoch mit der Frage um das Homeoffice (WireGuard + RDP) mit einem PrivatPC. Hier kann der Nutzer ja nicht die Adminrechte entzogen werden.
Leider ist es auch unter Linux so, bei Android sind die Keys versteckt. Ein anderer Client ist mir nicht bekannt, auch NCP macht kein WireGuard. Es wird also so sein, dass ich für diesen Zweck kein Wireguard nutzen kann.
Bei Android wird lediglich der private Schlüssel und sofern vorhanden der PSK ausgeblendet, wenn man den oder die Tunnel exportiert sind allerdings alle Daten vorhanden! So erhält der Otto-Normal-Anwender dann leider ebenfalls alle Daten, es ist also kein reines Windows-Ding.
Es gäbe da ggf. schon eine Möglichkeit die Daten (unter Windows) etwas zu schützen, das hält dann zumindest den gemeinen Anwender von einer simplen Kopie ab.
Die Gretchenfrage ist allerdings, woran man diese zusätzliche Sicherheit, sprich die Verschlüsselung der Konfiguration, fest macht.
Da es das gleiche Problem bei OpenVPN gibt, musste da mal etwas für einen Kunden entwickelt werden.
Darüber möchte ich an dieser Stelle im Detail nicht sprechen, da sonst unter Umständen dieses Plus an Sicherheit ausgehebelt wird.
Bei Bedarf gerne eine Anfrage an meine Firma stellen.
Hallo Andy,
ich betreibe eine nextcloud, welche nur per VPN erreichbar ist.
Nun möchte ich dem einen oder anderen Zugriff zur nextcloud erlauben, ohne das er jedoch andere IPs im Netzwerk erreichen kann.
Könnte ich das über AllowedIPs lösen, also das nur die Verbindung zur nextcloud erlaubt ist oder kann man dann auch weiter im Netzwerk?
Ein Tipp wäre toll!
Vielen Dank
Bodo
Über Allowed IPs, wenn das so überhaupt funktioniert, wäre mir zu unsicher, da der Anwender das einfach selbst ändern kann und dann auf das gesamte Netz Zugriff hätte.
Das Ganze ist eher ein Thema für die Firewall, in der man eine Regel festlegt, das die betroffene WireGuard-(Client)-IP eben nur zur Nextcloud kann und mehr nicht.
Tolle Hilfestellung für unser Vorhaben im Unternehmensumfeld.
Leider stecke ich schon im ersten Teil der Erstellung des RegKeys fest: “Zugriff verweigert”. Als Hauptbenutzer, als auch als Admin. Bei mir existiert HKLMSoftwareWireGuard auch nicht. mache ich was falsch?
Auch als admin ist es wichtig die Befehle in einer Eingabeaufforderung oder regedit jeweils mit erhöhten Rechten auszuführen!
Mal versuchen alles Schritt-für-Schritt per regedit zu erstellen und schauen ob das a) klappt und b) wenn nicht, ab welcher Stelle es Schwierigkeiten gibt.
Hallo,
das Thema hat aber dann einen Haken, wenn man mit Microsoft 365 Konten aus der Azure AD arbeitet. Dann klappt es nicht mit dem hinzufügen, zumindest ist es mir bisher nicht gelungen. Gibt es da eine Alternative?
Als “Plan B” kann man mit einer Aufgabe arbeiten:
Windows: Aufgaben durch andere Benutzer ausführen lassen
Ich habe auf meinem Win10 Client IPforwarding enabled (wegen WSL).
Wenn das an ist, kann ich mich mit keinem Wireguard-Server verbinden.
Das Problem ist dann wohl das Routing. Im Log steht auch:
the “Ethernet” interface has Forwarding/WeakHostSend enabled
Das per Powershell an und aus zu machen ist keine Lösung. Kann ich da mit einer statischen Route was machen ?
Dane und Grüße,MG
Hi, ich habe soeben unter Windows erfolglos probiert mehrere Wireguard-Tunnel gleichzeitig aufzubauen. Habe zu diesem Zweck folgendes in die Registry eingetragen:
[HKEY_LOCAL_MACHINESOFTWAREWireGuard]
“MultipleSimultaneousTunnels”=dword:00000001
Funktioniert aber bei mir nicht! Der erste Tunnel wird immer abgebaut sobald ich probiere den zweiten aufzubauen! WireGuard Client ist 0.5.3 … hat Jemand eine Idee?
@Nico ich weiß etwas spät:
ja, es wird so sein, dass deine Tunnel entweder das gleiche Tunnelsubnetz haben (z.B. 10.10.10.0/24) oder Deine allowed IPs in beiden Netzten sind auch das gleiche Subnetz.
Das geht natürlich nicht und deshalb wird der alte Tunnel abgebaut.
Baue deshalb z.b. 10.10.1.0/24 und 10.10.2.0/24
Wenn Du das beachtest gehen mit Wireguard auch mehrere Tunnel glichzeitg by default.
Hallo Andy,
ist eigentlich aus dem “Ausblick: Ich arbeite an einem Skript und Tool, das nach dem Start des Tunnels signalisiert, das eine Verbindung besteht.” was geworden?
Insgesamt habe ich aber auch noch ein anderes Problem: Ich habe hier eine Windows 10 Home und kann weder Netzwerkkonfigurations-Operatoren einrichten, noch Standardnutzern das Recht zum starten bestimmter Dienste geben.
Die jeweiligen Menü’s für die Zuteilung der Rechte fehlen schlicht und ergreifend.
Wüsstest du da eine Lösung?
Viele Grüße
Hallo Konrad,
immer wenn es sich ergibt arbeite ich an dem Tool weiter, da ich allerdings damit noch nicht ganz zufrieden bin, wurde es halt noch nicht veröffentlicht.
Zu Windows Home-Editionen kann ich nichts beitragen, da wir diese nicht verwenden.
Vermutlich kann man das Ganze wie im Beitrag erwähnt über eine Aufgabe lösen.
Hallo Andy,
besteht irgendwie auch die Möglichkeit, dass ich Wireguard noch vor des Logon von Windows starten kann? Quasi mit Aufbau der Netzwerkverbindung?
Ich habe eine Domäne eingerichtet (Synology Active Directory, da kleines Unternehmen). Wenn ich nun außerhalb meines Netzwerkes bin, kann ich mich zwar in der Domäne anmelden, jedoch nicht auf die gemappten Laufwerke zugreifen. Bevor ich jetzt ein Autostart Script schreibe, wäre mir die Lösung eines direkten Aufbaus lieber.
Hier wäre die nächste “Hürde” die Unterscheidung ob ich im Netzwerk bin oder nicht…
Kurz: Wenn im Firmennetzwerk (Zuweisung bestimmte IP), dann nichts machen, wenn nicht im Firmennetzwerk, dann Wireguard Profil starten.
Windows hat über sein internes VPN die Möglichkeit dazu geschaffen, unterstützt aber kein Wireguard :-(.
Hallo Andy,
vielleicht hilft das dem ein oder anderen…
Wir haben einen Draytek Router mit zugehörigem Draytek VPN Client. Dieser unterstützt in der aktuellen Version auch Wireguard. Interessanterweise kann mit dem Client ein Wireguard Profil eingelesen werden und der Windows Benutzer (ohne Admin Rechte) kann das aktivieren und den Tunnel aufbauen.
Hallo Thomas,
das lässt sich alles machen, um’s Skripten kommt man allerdings nicht drum herum.
Man braucht halt ein Skript das prüft ob man im Firmen-Netz ist oder nicht und ob überhaupt Internet vorhanden ist oder nicht und dann entsprechend den Tunnel auf- bzw. abbaut.
Dieses Skript kann z.B. als Aufgabe (per Intervall oder per Ereignis) mit admin- oder System-Rechten ausgeführt werden. Alternativ ließe sich das auch mit einem eigenen Dienst machen.
Ich hab sowas mal vor einer Weile angefangen, ist allerdings nicht fertig.
Besten Dank für die Mühe eine Lösung zu finden. Trotzdem: Wireguard und Windows im Admin -Modus laufen zu lassen ist an Inkompetenz kaum zu überbieten. Bei Apple geht es anders. Ich habe keine Lust die Unfähigkeit von AVM durch stundenlange Bemühungen zu kompensieren. Wir reden von Datensicherheit und sollen einen VPN als Admin betreiben. Nein Danke.