Wie Sie unter Windows 11 einen Kill Switch ohne Drittanbieter-Software einrichten

Sie haben einen VPN-Anbieter im Einsatz und wollen einen Kill Switch. Sie wollen aber nicht noch eine zusätzliche Software installieren, die im Hintergrund läuft, Ressourcen frisst und nach jedem Update Ihre Einstellungen still und leise zurücksetzt. Windows 11 hat eine eingebaute Firewall, PowerShell und den Aufgabenplaner. Reicht das nicht?

Die Antwort lautet: ja, fast. Die meisten kommerziellen VPN-Clients (zum Beispiel Windscribes Windows VPN) bringen einen integrierten Kill Switch mit. Dieser Artikel ist für die Leser, die verstehen wollen, was unter der Haube passiert, und prüfen möchten, ob sich das Ganze mit Bordmitteln nachbauen lässt. Kurze Antwort vorab: Sie können einen funktionierenden Kill Switch in etwa zwanzig Minuten zusammenklicken. Es gibt aber sechs Stellen, an denen dieser Eigenbau leise scheitert. Beides bekommen Sie hier.

Reihenfolge: zuerst, was ein Kill Switch tatsächlich tut (weil die meisten Erklärungen daran scheitern). Dann der Aufbau. Dann ein Test. Dann der ehrliche Teil.

Was ein Kill Switch wirklich tut (und was die meisten falsch verstehen)

Ein Kill Switch ist kein einzelnes Feature. Er beschreibt zwei verschiedene Mechanismen auf zwei verschiedenen Ebenen. Erstens: ein systemweiter Kill Switch blockiert sämtlichen ausgehenden Netzwerkverkehr, sobald die VPN-Verbindung wegfällt, unabhängig davon, welche Anwendung gerade sendet. Zweitens: ein anwendungsbezogener Kill Switch blockiert ausschließlich den Verkehr bestimmter Programme (etwa eines BitTorrent-Clients oder eines bestimmten Browser-Profils), während der Rest des Systems online bleibt. Beide Ansätze haben ihre Berechtigung. Welcher passt, hängt davon ab, was Sie schützen wollen.

Wichtiger ist folgendes: Ein „VPN-Ausfall“ ist nicht ein einzelnes Ereignis, sondern drei. Erstens kann der virtuelle Netzwerkadapter zusammenbrechen, was leicht zu erkennen ist. Zweitens kann der VPN-Prozess abstürzen, während der TUN-Adapter noch lebt, was deutlich schwerer zu erkennen ist. Drittens kann der Tunnel zwar bestehen, der gesamte Traffic aber außerhalb des Tunnels geroutet werden, was am schwersten zu erkennen ist. Ein vernünftiger Kill Switch muss alle drei Fälle abfangen. Behalten Sie diese drei Szenarien im Kopf, sie kommen weiter unten wieder.

Der Windows-11-Eigenbau: Kill Switch mit Bordmitteln

Wir nutzen die Windows-Defender-Firewall mit erweiterter Sicherheit, eine Handvoll PowerShell-Befehle und (optional) den Aufgabenplaner. Sonst nichts.

Methode A: Systemweiter Kill Switch über die Windows-Firewall

Schritt 1: VPN-Adapter identifizieren. Verbinden Sie sich mit Ihrem VPN, öffnen Sie die Eingabeaufforderung und führen Sie ipconfig /all aus. Notieren Sie den Adapternamen. Typische Bezeichnungen sind „TAP-Windows Adapter“, „WireGuard Tunnel“ oder eine herstellerspezifische TUN-Schnittstelle.

Schritt 2: Erweiterte Firewall öffnen. Drücken Sie Win + R und geben Sie wf.msc ein.

Schritt 3: Ausgehenden Verkehr standardmäßig blockieren. Klicken Sie links auf „Windows Defender Firewall mit erweiterter Sicherheit“, dann oben rechts auf „Eigenschaften“. Setzen Sie in allen drei Profilen (Domäne, Privat, Öffentlich) die Option „Ausgehende Verbindungen“ auf „Blockieren“. Achtung: ab diesem Moment verlässt kein Datenverkehr mehr Ihr System, bis Sie Erlaubnis-Regeln definieren. Führen Sie diesen Schritt nur mit aktiver VPN-Verbindung durch.

Schritt 4: Erlaubnisregel für den VPN-Adapter erstellen. Klicken Sie links auf „Ausgehende Regeln“ und dann rechts auf „Neue Regel“. Wählen Sie „Benutzerdefiniert“ als Regeltyp. Programm: alle Programme. Protokoll: beliebig. Bereich: beliebig. Aktion: Verbindung zulassen. Profil: alle drei aktivieren. Name: „VPN-Adapter Allow“.

Schritt 5: Regel an den VPN-Adapter binden. Öffnen Sie die soeben erstellte Regel, wechseln Sie zum Reiter „Erweitert“ und klicken Sie neben „Schnittstellentypen“ auf „Anpassen“. Wählen Sie ausschließlich Ihren VPN-Adapter aus. Falls die GUI diese Option ausgegraut anzeigt, hilft netsh aus der PowerShell weiter.

Schritt 6: VPN-Anwendung freigeben. Erstellen Sie eine zweite ausgehende Erlaubnisregel, diesmal mit Regeltyp „Programm“. Pfad: vollständiger Pfad zur ausführbaren Datei Ihres VPN-Clients (oder zu PowerShell, falls Sie die Verbindung per Skript aufbauen). So kann der Client den Tunnel überhaupt erst aufbauen, bevor die Sperre greift.

Schritt 7: DHCP und lokales DNS freigeben. Ohne diesen Schritt verwandelt sich Ihr Rechner beim ersten Profilwechsel in einen Briefbeschwerer. Erstellen Sie eine Regel, die DHCP (UDP 67/68) und DNS (UDP 53) ausschließlich zum lokalen Gateway im LAN-Subnetz erlaubt. Skopen Sie das Ganze auf den IP-Bereich Ihres Heimnetzes.

PowerShell-Auszug zum Kopieren:

netsh advfirewall set allprofiles firewallpolicy blockinbound,blockoutbound
New-NetFirewallRule -DisplayName "VPN-Adapter Allow" `
  -Direction Outbound -Action Allow `
  -InterfaceAlias "WireGuard Tunnel"

Methode B: Kill Switch nur für einzelne Anwendungen

Wer nicht das gesamte System lahmlegen, sondern nur einen bestimmten Torrent-Client, ein einzelnes Browser-Profil oder eine spezifische Anwendung absichern will, scopt die Sperre über programmbasierte Regeln. Erstellen Sie eine ausgehende Blockierregel für die jeweilige Anwendung und ergänzen Sie eine Erlaubnisregel, die ausschließlich auf den VPN-Adapter beschränkt ist. Effekt: das Programm fällt sofort aus, sobald der Tunnel abreißt, der Rest Ihres Systems läuft normal weiter. Praktisch, wenn Sie während eines Slack-Calls keinen totalen Netzausfall riskieren wollen, der P2P-Client aber nicht eine Sekunde länger ohne VPN senden darf.

Persistenz: das Skript, das die meisten Anleitungen vergessen

Windows-Updates, Profilwechsel und Gruppenrichtlinien-Refreshes haben die unangenehme Angewohnheit, Firewall-Regeln stillschweigend zu verändern oder zurückzusetzen. Schreiben Sie ein kurzes PowerShell-Skript, das Ihre Regeln neu anwendet, und planen Sie es im Aufgabenplaner so, dass es bei jeder Benutzeranmeldung läuft. Sechs Zeilen reichen. Ohne diese Persistenz haben Sie nach dem nächsten Funktionsupdate einen Kill Switch, der nicht mehr existiert, aber so aussieht, als würde er noch greifen. Das ist gefährlicher als gar kein Kill Switch.

Testen Sie, bevor Sie sich darauf verlassen

Ein nicht getesteter Kill Switch erzeugt falsches Vertrauen, und falsches Vertrauen ist schlimmer als gar kein Kill Switch. Drei Tests reichen.

Test 1: Sauberes Trennen. Trennen Sie die VPN-Verbindung über den Client. Öffnen Sie einen Browser. Versuchen Sie, eine beliebige Website zu laden. Ergebnis: Verbindungsfehler oder DNS-Auflösungsfehler. Wenn eine Seite lädt, ist Ihre Standard-Block-Regel nicht aktiv.

Test 2: Hartes Beenden. Beenden Sie den VPN-Prozess im Task-Manager über „Task beenden“, anstatt ihn über den Client zu trennen. Der Adapter kann dabei kurzzeitig oben bleiben. Das Ergebnis sollte trotzdem identisch zu Test 1 sein. Wenn doch Verkehr fließt, ist Ihre Regel an die falsche Schnittstelle gebunden. Diesen Test überspringen die meisten Anleitungen, und genau er belegt, ob die Bindung sauber sitzt.

Test 3: DNS-Leak-Test bei aktiver Verbindung. Rufen Sie bei aktivem VPN eine bekannte Leak-Test-Seite auf (zum Beispiel dnsleaktest.com oder browserleaks.com). Die angezeigten DNS-Server müssen zum VPN-Anbieter gehören, nicht zu Ihrem ISP. Die Windows-Firewall erzwingt von sich aus keine DNS-Umleitung. Wenn Ihr VPN-Client kein eigenes DNS pusht, leakt Ihre Konfiguration auch dann, wenn der Kill Switch funktioniert.

Falls Test 3 Sie unangenehm überrascht hat, sehen Sie den ersten Riss im Eigenbau. Es gibt mehr.

Wo der Windows-Firewall-Ansatz scheitert

1. DNS-Leaks

Firewall-Regeln steuern, welcher Verkehr das System verlassen darf, nicht, an welchen DNS-Server die Anfragen gehen. Wenn Ihr VPN-Client keine eigenen DNS-Server erzwingt, gehen Ihre Anfragen weiterhin an den ISP. Die Firewall sieht das als zulässigen ausgehenden DNS-Verkehr und winkt ihn durch.

2. IPv6-Bypass

Die meisten VPN-Tunnel sind IPv4-only. Wenn Ihr ISP einen Dual-Stack-Anschluss bereitstellt und der Tunnel IPv6 nicht abdeckt, blockieren die oben angelegten Regeln den IPv6-Verkehr nicht, solange Sie keine expliziten IPv6-Sperrregeln ergänzen. Verifizieren lässt sich das mit einem IPv6-Leak-Test.

3. VPN-Prozess abgestürzt, Adapter noch oben

Erinnern Sie sich an die drei Ausfallszenarien aus dem ersten Abschnitt? Der Firewall-Ansatz fängt Fall eins ab (Adapter weg). Fall zwei (Prozess tot, Adapter lebt noch) erkennt er nicht. Manche VPN-Clients ziehen den Adapter beim Absturz hinterher, andere nicht. Sie haben darauf keinen Einfluss.

4. Keine automatische Wiederverbindung

Ein vollwertiger Kill Switch trennt nicht nur, er stellt die Verbindung auch wieder her und routet den Traffic, sobald der Tunnel zurück ist, ohne ihn zwischendurch ungeschützt herauszulassen. Die Windows-Firewall erledigt den ersten Teil, nicht den zweiten. Wiederverbindung ist Ihre Aufgabe oder die eines zusätzlichen Watcher-Skripts.

5. Regel-Verfall

Updates, neue Netzwerkprofile (etwa beim Wechsel ins WLAN eines Cafés), Gruppenrichtlinien-Refreshes: jede dieser Operationen kann Firewall-Regeln verändern oder löschen. Das Persistenz-Skript aus dem Aufbau-Abschnitt mildert das ab, beseitigt es aber nicht. Sie müssen den Zustand selbst überwachen.

6. Kein Split-Tunneling auf Tunnel-Ebene

Selektives Routing einzelner Anwendungen über den VPN, während andere die normale Leitung nutzen, lässt sich mit Firewall-Regeln nicht sauber abbilden. Sie haben Alles-oder-Nichts.

Die meisten dieser Lücken sind in der Windows-Firewall nicht reparierbar. Sie sind reparierbar in Software, die das tut, was die Firewall nicht tut.

Was ein VPN-eigener Kill Switch leistet, den der Eigenbau nicht abdeckt

Ein client-seitiger Kill Switch erzwingt VPN-eigene DNS-Server (Lücke 1). Er bindet sich an den Prozesszustand des VPN-Clients, nicht nur an den Adapter (Lücke 3). Er übernimmt die automatische Wiederverbindung (Lücke 4). Er reagiert auf Profilwechsel und Sleep-Wake-Zyklen, ohne dass Sie eine geplante Aufgabe pflegen müssen (Lücke 5). Er bietet in den meisten Fällen Split-Tunneling an (Lücke 6). IPv6 (Lücke 2) handhabt er entweder durch vollständige Tunnelung oder durch das gezielte Blockieren des nativen IPv6-Stacks bei Verbindungsabbruch.

Die meisten seriösen VPN-Anbieter liefern das mit. Windscribes Windows-Client kombiniert beispielsweise einen Standard-Kill-Switch mit einem „Firewall“-Modus, der auf der Netzwerkebene fail-closed arbeitet (also derselbe Ansatz wie der DIY-Eigenbau, aber aus dem Client heraus erzwungen und nach jedem Reconnect frisch aufgebaut). Bevor Sie sich für den Eigenbau entscheiden, prüfen Sie, was Ihr aktueller Client in jedem der sechs oben genannten Fälle tatsächlich tut. Vielleicht haben Sie das Feature längst, ohne es zu wissen.

Wenn Sie den Eigenbau gemeistert haben, haben Sie die architektonische Arbeit ohnehin geleistet. Die ehrliche Frage ist, ob Sie sie auf Dauer pflegen wollen.

FAQ