Die Kurzfassung: Eine VPN-Verbindung ist kein dauerhafter Zustand – sie ist eine Netzwerksitzung, die unterbrochen werden kann. WLAN-Roaming, Übergaben zwischen Mobilfunkmasten, Server-Neustarts, Paketverlustspitzen, App-Unterbrechungen und Sleep-Zyklen des Betriebssystems unterbrechen den Tunnel regelmäßig. Fällt der Tunnel aus, gilt die Standard-Routing-Regel des Betriebssystems: „Falls keine spezifische Route vorhanden ist, nutze das physische Interface“ – dein Datenverkehr fällt also auf deine echte Verbindung zurück und sendet deine echte IP an jeden, mit dem du gerade kommuniziert hast. Ein Kill-Switch ist der Mechanismus, der sagt: „Nein, stopp den Datenverkehr, bis der Tunnel wieder verfügbar ist.“ Konzeptionell simpel. Bei der Implementierung wird der Begriff jedoch für mindestens drei recht unterschiedliche Dinge verwendet – mit sehr verschiedenen Fehlerbildern.
Warum Kill-Switches existieren – das Problem des stillen Fallbacks
Stell dir vor, was ohne Kill-Switch passiert. Du bist in einem Café, das VPN ist verbunden. Du liest E-Mails über einen Webmail-Client. Das WLAN hat einen kurzen Ausfall – vielleicht zwei Sekunden. Der VPN-Client versucht, die Verbindung wiederherzustellen, aber das zugrundeliegende Netzwerk ist weg, sodass der Neuverbindungsversuch scheitert. Nach 30 Sekunden kommt das Netzwerk zurück. Was jetzt passiert, hängt vom Verhalten des VPN-Clients ab:
- Ohne Kill-Switch – sobald das WLAN zurückkommt, fällt die Standard-Route deines Betriebssystems auf das WLAN-Interface zurück. Der VPN-Client versucht noch zu reconnecten, aber deine Apps warten nicht. Die Hintergrundsynchronisierung deines Webmail-Clients sendet die nächste Anfrage über das ungeschützte WLAN – mit deiner echten IP und dem DNS-Resolver, den das Netzwerk dir zugewiesen hat. Bis das VPN die Verbindung wiederhergestellt hat (5–20 Sekunden später), ist der Leak bereits passiert.
- Mit Kill-Switch – wenn das VPN trennt, installiert der Kill-Switch eine Firewall-Regel, die den gesamten Datenverkehr blockiert, der nicht durch den Tunnel läuft. Auch wenn das WLAN zurückkommt, können deine Apps nichts senden, bis die VPN-Sitzung vollständig wiederhergestellt ist. Die Synchronisierungsanfrage deines Webmail-Clients scheitert mit einem Netzwerkfehler (die App versucht es erneut), aber kein Datenverkehr verlässt dein Gerät über das ungeschützte Interface.
Das Problem des stillen Fallbacks ist genau das, was Kill-Switches lösen sollen. Es geht nicht darum, dass „das VPN abgestürzt ist und ich jetzt ungeschützt surfe“ – sondern um den viel subtileren Fall, in dem das VPN kurz nicht verfügbar ist, deine Apps das nicht wissen und in der Lücke Daten leaken.
Die drei Arten von Kill-Switches
Wenn Anbieter „Kill-Switch“ sagen, können sie jede dieser drei Architekturen meinen. Die Unterschiede sind wichtig, weil sich die Fehlerbilder unterscheiden.
1. Systemweiter Kill-Switch (Firewall-basiert)
Das stärkste Modell. Der VPN-Client installiert eine Firewall-Regel im Betriebssystem – per pf unter macOS, der Windows Filtering Platform unter Windows, iptables oder nftables unter Linux oder einer System-Netzwerkerweiterung unter iOS/Android – die jedes ausgehende Paket verwirft, das nicht für die IP des VPN-Servers bestimmt ist. Wenn das VPN aktiv ist, leitet der Tunnel selbst den Datenverkehr zum VPN-Server weiter, sodass Pakete passieren können. Wenn das VPN nicht aktiv ist, passt nichts zur „Erlauben“-Regel, und alles wird blockiert. Die Firewall-Regel bleibt auch dann bestehen, wenn der VPN-Client abstürzt, da die Betriebssystem-Firewall unabhängig von der Anwendung ist, die die Regel installiert hat.
2. App-Level-Kill-Switch (anwendungsbezogen)
Statt den gesamten Datenverkehr zu blockieren, blockiert der Kill-Switch nur bestimmte Apps, die du einer Liste hinzugefügt hast. Fällt das VPN aus, verlieren diese Apps die Netzwerkverbindung, bis das VPN zurückkommt; andere Apps funktionieren weiterhin normal. Das ist für sehr spezifische Szenarien nützlich – zum Schutz eines bestimmten Browsers, IRC-Clients oder BitTorrent-Clients – als allgemeine Schutzmaßnahme ist es jedoch schwächer, da eine große Angriffsfläche verbleibt (die System-Tray-Apps, Hintergrunddienste, OS-Komponenten und die Apps, die du vergessen hast hinzuzufügen).
3. Netzwerkseitige Firewall (Always-on VPN)
Unter Android gibt es eine stärkere Grundfunktion als die Kill-Switches, die VPN-Apps selbst implementieren: die systemseitige Einstellung „Always-on VPN“ mit aktiviertem „Verbindungen ohne VPN blockieren“. Hier erzwingt das Betriebssystem selbst die Regel – Android weigert sich, jeglichen Nicht-VPN-Datenverkehr weiterzuleiten, unabhängig davon, welche App anfrägt. Selbst wenn die VPN-App abstürzt, hält das Betriebssystem die Linie. Dies ist das robusteste Kill-Switch-Verhalten, das auf Mobilgeräten verfügbar ist, und es ist unbedingt stärker als app-implementierte Kill-Switches.
Wie jede Art tatsächlich auf der OS-Ebene funktioniert
Die Implementierungsdetails sind wichtig, weil sie die Fehlerbilder vorhersagen. Ein Firewall-basierter Kill-Switch versagt, wenn die Firewall-API fehlerhaft ist. Ein app-basierter Kill-Switch versagt, wenn die App abstürzt. Ein betriebssystem-erzwungenes Always-on-VPN versagt praktisch nie – es sei denn, du startest im abgesicherten Modus neu.
iOS-Implementierung – NetworkExtension und On-Demand-Regeln
iOS stellt Drittanbieter-VPN-Apps keine direkte „Kill-Switch“-API zur Verfügung. Was es bereitstellt, ist der Mechanismus der „On-Demand-Regeln“ des NetworkExtension-Frameworks: Regeln, die besagen: „Wann immer eine App eine Netzwerkverbindung herstellen möchte, die keiner Ausnahme entspricht, erzwinge zuerst die VPN-Verbindung.“ Wenn das VPN keine Verbindung herstellen kann, hängt die Verbindungsanfrage. Aus Sicht des Benutzers verhält sich das wie ein Kill-Switch – tatsächlich ist es aber eine „VPN erzwingen“-Regel, keine „alles blockieren, wenn VPN inaktiv ist“-Regel. Das funktionale Ergebnis ist ähnlich; die Implementierung ist anders.
Die NetworkExtension-API unterstützt auch das includeAllNetworks-Flag (hinzugefügt in iOS 14), das das VPN zu einem systemseitigen Netzwerkfilter macht – sogar Datenverkehr vom Kernel und von Systemdiensten wird durch das VPN gezwungen. Mit gesetztem Flag funktioniert das VPN tatsächlich als vollständiger Kill-Switch, wobei das Betriebssystem garantiert, dass kein Datenverkehr außerhalb des Tunnels entkommt. Nicht jeder VPN-Anbieter aktiviert es; das Flag hat Auswirkungen auf die Kompatibilität.
Android-Implementierung – Always-on VPN + Verbindungen ohne VPN blockieren
Androids stärkstes Kill-Switch-Verhalten findet sich unter Einstellungen, dann Netzwerk & Internet, dann VPN, dann dem Zahnrad-Symbol neben deinem VPN und dann den zwei Schaltern: „Always-on VPN“ und „Verbindungen ohne VPN blockieren.“ Wenn beide aktiviert sind, weigert sich das Android-System selbst – nicht die VPN-App – den Datenverkehr weiterzuleiten, bis das VPN verbunden ist. Die VPN-App kann abstürzen, zwangsbeendet oder deinstalliert werden, und die Regel bleibt bestehen. Die offizielle Android-Entwicklerdokumentation beschreibt den Mechanismus detailliert. Dies ist der Goldstandard für Kill-Switch-Verhalten auf mobilen Verbrauchergeräten.
macOS-Implementierung – System-Netzwerkerweiterungen
macOS 11 (Big Sur) und spätere Versionen führen VPNs über das System Extension Framework aus – dieselbe Architektur, die Inhaltsfilter und systemseitige Netzwerkfilter unterstützt. Der Kill-Switch wird typischerweise als Paketfilter-Regel (pf) implementiert, die vom VPN-Client installiert wird, kombiniert mit einer Netzwerkerweiterung, die die Routing-Tabellen-Änderung hält. Wenn das VPN abbricht, bleibt die pf-Regel in Kraft und blockiert weiterhin den Datenverkehr, bis das VPN sich wieder verbindet. Wenn der VPN-Client selbst abstürzt, hängt das Verhalten davon ab, ob die Systemerweiterung so konfiguriert ist, dass sie geladen bleibt – gut gestaltete Clients halten die Regeln aufrecht; schlecht gestaltete Clients entfernen sie beim Absturz und leaken.
Windows-Implementierung – Windows Filtering Platform
Windows-VPNs implementieren den Kill-Switch typischerweise durch das Installieren von WFP-Filterregeln (Windows Filtering Platform), die den Datenverkehr auf dem physischen Adapter blockieren und gleichzeitig den Datenverkehr auf dem virtuellen VPN-Adapter erlauben. Die Filter bleiben über VPN-Client-Prozessneustarts hinaus bestehen (sie gehören der Kernel-Filterschicht, nicht der Benutzerraum-App), sodass der Filter auch dann bestehen bleibt, wenn die VPN-App abstürzt. Das Risiko besteht darin, dass einige VPN-Clients minderwertige Firewall-Regelstrategien verwenden – z. B. das Manipulieren der Windows Defender-Firewall über PowerShell oder netsh – die durch andere Firewall-Regeln oder Fehlkonfigurationen umgangen werden können.
Wenn Kill-Switches versagen – bekannte Leak-Bedingungen
Ein Kill-Switch ist keine perfekte Garantie. Es gibt gut dokumentierte Bedingungen, unter denen Datenverkehr selbst bei aktiviertem Kill-Switch leaken kann. Jeder VPN-Anbieter geht unterschiedlich damit um; manche werden durch sorgfältige Implementierung behoben, andere sind ohne OS-Level-Kooperation unvermeidbar.
DNS-Vergiftung beim Verbindungsaufbau
Um eine Verbindung zum VPN-Server herzustellen, muss der VPN-Client zunächst den Hostnamen des Servers auflösen. Wenn der Kill-Switch „kein Datenverkehr ohne VPN“ erzwingt, der VPN-Client selbst aber einen DNS-Lookup durchführen muss, um den VPN-Server zu finden, muss es eine Ausnahme geben – und diese Ausnahme ist eine kleine Leak-Angriffsfläche. Ein bösartiges lokales Netzwerk könnte die DNS-Antwort vergiften und den VPN-Client zu einem gefälschten Server umleiten. Die meisten Clients umgehen dies, indem sie eine fest kodierte IP für den VPN-Server verwenden oder das TLS-Zertifikat pinnen, sodass ein umgeleiteter Server nicht validiert. Günstige VPN-Clients überspringen diesen Schritt manchmal.
IPv6-Leaks
Wenn dein Netzwerk IPv6-Konnektivität hat, der Kill-Switch des VPN-Clients aber nur IPv4-Datenverkehr blockiert, kann dein IPv6-Datenverkehr über das ungeschützte Interface fließen, selbst wenn der Kill-Switch „aktiv“ ist. Dies ist einer der häufigsten realen Leak-Modi. Die Lösung besteht darin, dass der VPN-Client passende IPv6-Firewall-Regeln installiert. Viele ältere Clients tun das nicht. Teste nach dem Aktivieren eines Kill-Switches immer auf IPv6-Leaks, indem du einen Leak-Test durchführst.
Captive Portals (WLAN-Anmeldeseiten)
Cafés, Flughäfen und Hotels verlangen oft, dass du dich über ein Captive Portal anmeldest, bevor du das Internet – einschließlich des VPN-Servers – erreichen kannst. Ein strenger Kill-Switch verhindert, dass du das Captive Portal erreichst, weil es kein VPN-Server ist. Die meisten VPN-Clients haben einen „Kill-Switch für Captive Portal pausieren“-Modus, den du manuell aktivieren musst. Während der Pause bist du ungeschützt, also browse nichts Sensibles, bis der Kill-Switch wieder aktiv ist. Das betriebssystem-native Always-on-VPN unter Android geht damit dank der systemseitigen Captive-Portal-Erkennung etwas eleganter um, aber der Kompromiss ist derselbe.
App-Suspend und Hintergrund-Neustart-Races
Auf Mobilgeräten kann das Betriebssystem die VPN-App zur Akku-Schonung suspendieren. Wenn die App fortgesetzt wird, gibt es ein kleines Zeitfenster, in dem der Tunnel wiederhergestellt wird. Wenn der Kill-Switch auf OS-Ebene implementiert ist (über includeAllNetworks auf iOS oder Always-on-VPN auf Android), gibt es keinen Leak. Wenn der Kill-Switch rein in der App implementiert ist, kann es ein kurzes Fenster geben, in dem das Betriebssystem Apps wieder gestartet hat, das VPN aber noch nicht verbunden ist, und Apps, die in diesem Fenster Netzwerkaufrufe tätigen, werden leaken.
Boot-Zeit-Race
Auf dem Desktop ist der Zeitraum zwischen dem Booten und dem Start des VPN-Clients ungeschützt. Netzwerkbewusste Apps, die automatisch starten (Mail, Slack, Steam, Systemaktualisierungsprüfungen), stellen oft Verbindungen her, bevor das VPN aktiv ist. Ein robuster Kill-Switch installiert seine Firewall-Regel als persistente Boot-Zeit-Regel, sodass der Datenverkehr auch beim Booten blockiert wird, bis das VPN verbunden ist. Die meisten Verbraucher-VPN-Clients tun dies nicht; die Regel gilt erst, nachdem der Client gestartet ist.
Kill-Switch-Typen im Vergleich
| Typ | Was er blockiert | OS-Unterstützung | Häufige Fehlerbilder |
|---|---|---|---|
| Systemweite Firewall | Gesamter Nicht-VPN-Datenverkehr auf Kernel-Ebene | macOS, Windows, Linux; iOS über includeAllNetworks | IPv6-Leaks bei reinen IPv4-Regeln; Boot-Zeit-Race; DNS-Bootstrap-Ausnahme |
| App-Level (anwendungsbezogene Blockliste) | Nur Datenverkehr gelisteter Apps | Windows, einige macOS-Clients | Apps außerhalb der Liste leaken weiter; OS-Komponenten leaken; Systemdienste leaken |
| OS-erzwungenes Always-on-VPN | Gesamter Datenverkehr auf OS-Ebene, unabhängig von App-Abstürzen | Android (Always-on VPN + Blockieren ohne VPN), iOS (NetworkExtension On-Demand) | Captive-Portal-Anmeldung wird blockiert, bis du pausierst; kaum andere Fehlerbilder |
| Anwendungsmonitor (die schwache Form) | Nichts direkt; schließt lediglich angegebene Apps, wenn das VPN abbricht | Einige Windows-Clients bieten dies noch an | Race zwischen Erkennung und Schließen führt zu Leaks; eigentlich kein echter Kill-Switch |
Was „Always-on VPN“ dir wirklich bietet, was ein App-Level-Kill-Switch nicht kann
Der wichtigste Unterschied im Jahr 2026 ist der zwischen vendor-implementierten Kill-Switches und OS-erzwungenen Always-on-VPNs. Hier ist, warum die OS-erzwungene Version deutlich stärker ist:
- Überlebt VPN-App-Abstürze. Wenn die VPN-App aus irgendeinem Grund abstürzt, stirbt ein app-seitiger Kill-Switch mit ihr. Die von ihr installierte Firewall-Regel bleibt je nach Implementierung möglicherweise bestehen oder auch nicht. Eine OS-erzwungene Regel wird vom Betriebssystem selbst gehalten und gilt weiterhin.
- Überlebt Neustarts. Viele app-seitige Kill-Switches installieren Regeln beim App-Start und entfernen sie beim Beenden, wodurch beim Booten eine Lücke entsteht. OS-Level-Always-on-Einstellungen werden ab dem ersten Netzwerkpaket berücksichtigt, das das Betriebssystem nach dem Boot weiterleitet.
- Deckt Systemdienste ab. Cloud-Synchronisierung, Prüfungen auf OS-Updates, Push-Notification-Daemons und andere OS-Level-Dienste laufen nicht durch normales VPN-Client-Routing. OS-erzwungenes Always-on deckt sie ab; ein app-seitiger Kill-Switch möglicherweise nicht.
- Kann nicht durch Benutzerfehler umgangen werden. Ein app-seitiger Kill-Switch hat einen Schalter in der App-Benutzeroberfläche. Ein Benutzer (oder eine andere App mit Berechtigungen) kann ihn deaktivieren. OS-Level-Always-on befindet sich in den Systemeinstellungen und ist schwerer versehentlich zu deaktivieren.
Unter Android bevorzugst du die OS-erzwungene Version: Aktiviere „Always-on VPN“ und „Verbindungen ohne VPN blockieren“ in den Systemeinstellungen und betrachte den eigenen Kill-Switch des VPN-Clients als Ergänzung. Unter iOS such nach VPN-Clients, die includeAllNetworks aktivieren; das ist das äquivalente Flag und bietet ähnliche Garantien.
Was Casper tut – die ehrliche Antwort
Casper's Cloak verwendet auf jeder Plattform einen OS-integrierten Kill-Switch – includeAllNetworks auf iOS, damit das Betriebssystem selbst die No-Leak-Regel durchsetzt, die Always-on-VPN-Einstellungen auf Android und Paketfilter-Regeln auf Kernel-Ebene unter macOS. Das Verhalten ist auf allen drei Plattformen gleich: Wenn der Tunnel abbricht, stoppt der gesamte Datenverkehr – einschließlich IPv6 und OS-Level-Dienste. Wenn der Tunnel zurückkommt, wird der Datenverkehr fortgesetzt. Es gibt keinen Schalter, den man vergessen kann, keine App-Liste, die man pflegen muss, keinen IPv6-Ausschnitt.
Wir ergänzen das mit Bedrohungsschutz und Bedrohungsschild für aktive Filterung gegen bekannte bösartige Domains, sodass der Tunnel nicht nur eine Routing-Schicht ist – er lehnt aktiv Verbindungen zu Phishing, Malware-C2 und bekannt schlechter Infrastruktur ab. Der Kill-Switch ist die unterste Schicht, die garantiert, dass nichts die Filterung umgeht, wenn der Tunnel kurz abbricht. Der kombinierte Effekt: Selbst in feindlichen Netzwerken wie denen, die in unserem Artikel über öffentliche WLAN-Angriffe beschrieben werden, gibt es kein „zwei Sekunden Klartext“-Fenster, das ein rein app-seitiger Kill-Switch offenlässt.
Unsere Position zu Kill-Switches generell: Es ist eine Mindesterwartung, kein Premium-Feature. Jedes Verbraucher-VPN, das 2026 keinen Kill-Switch anbietet, vermisst einen grundlegenden Sicherheitsmechanismus. Den architektonischen Hintergrund, warum das auf Systemebene wichtig ist, liefert das NSA-Leitfaden zur Auswahl und Härtung von Remote-Access-VPNs mit detaillierten Empfehlungen zugunsten von Full-Tunnel-Architekturen mit Kernel-Level-Durchsetzung.
Fazit
„Hat dieses VPN einen Kill-Switch“ ist die falsche Frage. Die richtigen Fragen sind: Wo im Stack wird der Kill-Switch durchgesetzt (App, System oder OS), deckt er IPv6 ab, bleibt er über App-Abstürze und Neustarts hinaus bestehen, und ist er standardmäßig aktiviert? Wenn die Antworten „OS-Level“, „ja“, „ja“ und „ja“ lauten, tut der Kill-Switch seinen Job. Wenn die Antworten „nur App-Level“, „nein“, „kommt drauf an“ und „standardmäßig deaktiviert“ lauten, hast du einen Kill-Switch dem Namen nach, aber nicht dem Schutz nach.
Die einfache Praxis: Aktiviere unter Android das systemseitige Always-on-VPN mit „Verbindungen ohne VPN blockieren“. Verwende unter iOS einen VPN-Client, der includeAllNetworks aktiviert. Überprüfe auf dem Desktop nach der Installation durch einen Leak-Test, trenne dann kurz die VPN-Serververbindung (oder ziehe dein Netzwerkkabel heraus) und bestätige, dass der Datenverkehr tatsächlich stoppt. Wenn der Leak-Test noch deine echte IP anzeigt, funktioniert der Kill-Switch nicht wie angegeben – untersuche das, bevor du ihm vertraust.