De korte versie: een VPN-verbinding is geen permanente toestand — het is een netwerksessie die kan wegvallen. Wi-Fi-roaming, wissels van zendmasten, serverherstart, piekverliezen in pakketten, app-suspensies en slaapstand van het besturingssysteem onderbreken de tunnel regelmatig. Als de tunnel wegvalt, zegt de standaardrouteringsregel van het besturingssysteem: "Als er geen specifieke route is, gebruik dan de fysieke interface" — wat betekent dat je verkeer terugvalt op je echte verbinding en je echte IP verstuurt naar alles waarmee je net communiceerde. Een killswitch is het mechanisme dat zegt: "Nee, stop gewoon met verkeer sturen totdat de tunnel weer actief is." Conceptueel simpel. In de praktijk wordt de term gebruikt voor minstens drie heel verschillende dingen, met sterk uiteenlopende faalscenario's.
Waarom killswitches bestaan — het probleem van stille terugval
Stel je voor wat er zonder een killswitch gebeurt. Je zit in een koffiebar met een actieve VPN. Je leest e-mail via een webmailclient. De Wi-Fi valt kort uit — misschien twee seconden. De VPN-client probeert opnieuw te verbinden, maar het onderliggende netwerk is weg en de herverbinding mislukt. Na dertig seconden komt het netwerk terug. Wat er dan gebeurt, hangt af van het gedrag van de VPN-client:
- Zonder killswitch — zodra Wi-Fi terugkomt, valt de standaardroute van je besturingssysteem terug op de Wi-Fi-interface. De VPN-client probeert nog steeds opnieuw te verbinden, maar je apps wachten niet. De achtergrond-sync van je webmail stuurt het volgende verzoek via het onbeschermde Wi-Fi, met je echte IP en de DNS-resolver die het netwerk je gaf. Tegen de tijd dat de VPN klaar is met herverbinden (5-20 seconden later), heeft het lek al plaatsgevonden.
- Met een killswitch — als de VPN verbreekt, installeert de killswitch een firewallregel die al het verkeer blokkeert dat niet via de tunnel gaat. Zelfs als Wi-Fi terugkomt, kunnen je apps niets versturen totdat de VPN-sessie volledig is hersteld. Het synchronisatieverzoek van de webmail mislukt met een netwerkfout (de app probeert het opnieuw), maar er verlaat geen verkeer je apparaat via de onbeschermde interface.
Het probleem van stille terugval is het centrale probleem dat killswitches oplossen. Het gaat niet om "de VPN is gecrasht en ik browse nu onbeschermd" — het gaat om het veel subtielere geval waarbij de VPN even niet beschikbaar is, je apps dat niet weten en ze lekken in die tussenfase.
De drie soorten killswitch
Als leveranciers zeggen "killswitch", kunnen ze elk van deze drie architecturen bedoelen. De verschillen zijn belangrijk omdat de faalscenario's ook verschillen.
1. Systeembrede killswitch (op basis van firewall)
Het sterkste model. De VPN-client installeert een firewallregel op het besturingssysteem — met pf op macOS, het Windows Filtering Platform op Windows, iptables of nftables op Linux, of een systeemnetwerkextensie op iOS/Android — die elk uitgaand pakket laat vallen dat niet gericht is op het IP-adres van de VPN-server. Als de VPN actief is, routeert de tunnel zelf verkeer naar de VPN-server, waardoor pakketten doorkomen. Als de VPN uitvalt, matcht niets de "toestaan"-regel en wordt alles geblokkeerd. De firewallregel blijft van kracht, zelfs als de VPN-client crasht, omdat de OS-firewall onafhankelijk is van de applicatie die de regel heeft geïnstalleerd.
2. Killswitch op app-niveau (per applicatie)
In plaats van al het verkeer te blokkeren, blokkeert de killswitch alleen specifieke apps die je aan een lijst hebt toegevoegd. Als de VPN uitvalt, verliezen die apps de netwerkverbinding totdat de VPN terugkomt; andere apps blijven normaal werken. Dit is handig voor zeer specifieke scenario's — het beschermen van een specifieke browser, IRC-client of BitTorrent-client — maar het is als algemene verdediging zwakker, omdat het een groot aanvalsoppervlak onbeschermd laat (de systray-apps, achtergrondservices, OS-componenten en de apps die je bent vergeten toe te voegen).
3. Firewall op netwerkniveau (always-on VPN)
Op Android specifiek is er een sterker mechanisme dan de killswitches die VPN-apps zelf implementeren: de systeembrede instelling "Altijd actieve VPN" met "Verbindingen zonder VPN blokkeren" ingeschakeld. Dit is het besturingssysteem zelf dat de regel handhaaft — Android weigert elk niet-VPN-verkeer te routeren, ongeacht welke app erom vraagt. Zelfs als de VPN-app crasht, houdt het besturingssysteem stand. Dit is het meest robuuste killswitch-gedrag dat beschikbaar is op mobiel en het is strikt sterker dan killswitches die door apps worden geïmplementeerd.
Hoe elk type feitelijk werkt op OS-niveau
De implementatiedetails zijn belangrijk omdat ze de faalscenario's voorspellen. Een op firewall gebaseerde killswitch faalt wanneer de firewall-API fouten bevat. Een op apps gebaseerde killswitch faalt wanneer de app crasht. Een door het OS afgedwongen always-on VPN faalt vrijwel nooit, tenzij je opstart in veilige modus.
iOS-implementatie — NetworkExtension en on-demand-regels
iOS biedt geen letterlijke "killswitch"-API aan externe VPN-apps. Wat het wel biedt, is het mechanisme van "on-demand-regels" van het NetworkExtension-framework: regels die zeggen "wanneer een app een netwerkverbinding probeert te maken die niet overeenkomt met een uitzondering, dwing dan eerst de VPN tot verbinding". Als de VPN geen verbinding kan maken, blijft het verbindingsverzoek hangen. Vanuit het perspectief van de gebruiker werkt dit als een killswitch — maar het is eigenlijk een "forceer VPN aan"-regel in plaats van een "blokkeer alles als VPN uitvalt"-regel. Het functionele resultaat is vergelijkbaar; de implementatie is anders.
De NetworkExtension-API ondersteunt ook de markering includeAllNetworks (toegevoegd in iOS 14), waarmee de VPN een netwerkfilter op systeemniveau wordt — zelfs verkeer van de kernel en systeemservices wordt via de VPN geleid. Met die markering ingesteld functioneert de VPN echt als een volwaardige killswitch, waarbij het besturingssysteem garandeert dat er geen verkeer buiten de tunnel ontsnapt. Niet elke VPN-leverancier schakelt dit in; de markering heeft gevolgen voor compatibiliteit.
Android-implementatie — Altijd actieve VPN + Verbindingen zonder VPN blokkeren
Het sterkste killswitch-gedrag op Android vind je via Instellingen, vervolgens Netwerk en internet, vervolgens VPN, vervolgens het tandwielicoon naast je VPN, en dan de twee schakelaars: "Altijd actieve VPN" en "Verbindingen zonder VPN blokkeren". Als beide zijn ingeschakeld, weigert het Android-systeem zelf — niet de VPN-app — verkeer te routeren totdat de VPN verbonden is. De VPN-app kan crashen, geforceerd worden gestopt of worden verwijderd, en de regel blijft van kracht. De officiële Android-ontwikkelaarsdocumentatie beschrijft het mechanisme in detail. Dit is de gouden standaard voor killswitch-gedrag op mobiele consumentenapparaten.
macOS-implementatie — systeemnetwerkextensies
macOS 11 (Big Sur) en later voert VPN's uit via het System Extension-framework — dezelfde architectuur die inhoudsfilters en netwerkfilters op systeemniveau ondersteunt. De killswitch wordt doorgaans geïmplementeerd als een pakketfilterregel (pf) die door de VPN-client wordt geïnstalleerd, gecombineerd met een netwerkextensie die de routetabelwijziging vasthoudt. Als de VPN wegvalt, blijft de pf-regel van kracht en blijft het verkeer geblokkeerd totdat de VPN opnieuw verbinding maakt. Als de VPN-client zelf crasht, hangt het gedrag ervan af of de systeemextensie is geconfigureerd om geladen te blijven — goed ontworpen clients houden de regels van kracht; slecht ontworpen clients laten ze vallen bij een crash en lekken dan.
Windows-implementatie — Windows Filtering Platform
Windows VPN's implementeren de killswitch doorgaans door Windows Filtering Platform (WFP)-filterregels te installeren die verkeer op de fysieke adapter blokkeren terwijl ze verkeer op de virtuele VPN-adapter toestaan. De filters blijven behouden bij het herstarten van het VPN-clientproces (ze zijn eigendom van de kernelfilterlaag, niet van de user-space-app), dus zelfs als de VPN-app crasht, blijft het filter van kracht. Het risico is dat sommige VPN-clients gebruik maken van minder hoogwaardige firewallregelstrategieën — bijv. het manipuleren van Windows Defender Firewall via PowerShell of netsh — die kunnen worden omzeild door andere firewallregels of door een verkeerde configuratie.
Wanneer killswitches falen — lekscenario's om te kennen
Een killswitch biedt geen perfecte garantie. Er zijn goed gedocumenteerde omstandigheden waaronder verkeer kan lekken, zelfs met een ingeschakelde killswitch. Elke VPN-leverancier gaat hier anders mee om; sommige worden aangepakt door zorgvuldige implementatie, andere zijn onvermijdelijk zonder samenwerking op OS-niveau.
DNS-vergiftiging tijdens de verbindingsopstart
Om verbinding te maken met de VPN-server moet de VPN-client eerst de hostnaam van de server omzetten. Als de killswitch "geen verkeer zonder VPN" afdwingt, maar de VPN-client zelf een DNS-opzoeking moet doen om de VPN-server te vinden, moet er een uitzondering zijn — en die uitzondering is een klein lekoppervlak. Een kwaadaardig lokaal netwerk kan het DNS-antwoord vergiftigen en de VPN-client omleiden naar een nep-server. De meeste clients lossen dit op door een vast IP voor de VPN-server te gebruiken, of door het TLS-certificaat te pinnen zodat een omgeleide server niet valideert. Goedkope VPN-clients slaan deze stap soms over.
IPv6-lekken
Als je netwerk IPv6-connectiviteit heeft maar de killswitch van de VPN-client alleen IPv4-verkeer blokkeert, kan je IPv6-verkeer via de onbeschermde interface lopen zelfs wanneer de killswitch "actief" is. Dit is een van de meest voorkomende lekscenario's in de praktijk. De oplossing is dat de VPN-client bijpassende IPv6-firewallregels installeert. Veel oudere clients doen dit niet. Test altijd op IPv6-lekken na het inschakelen van een killswitch door een lektest uit te voeren.
Captive portals (Wi-Fi-inlogpagina's)
Koffiebars, luchthavens en hotels vereisen vaak dat je inlogt via een captive portal voordat je het internet kunt bereiken — inclusief de VPN-server. Een strikte killswitch weigert je toegang tot de captive portal, omdat de captive portal niet de VPN-server is. De meeste VPN-clients hebben een modus "killswitch pauzeren voor captive portal" die je handmatig moet inschakelen. Terwijl de killswitch is gepauzeerd, ben je onbeschermd — blader dus niet naar iets gevoeligs totdat de killswitch weer actief is. De OS-native always-on VPN op Android gaat hier iets eleganter mee om via de systeemdetectie van captive portals, maar de afweging is dezelfde.
Races bij app-suspensie en achtergrondherstart
Op mobiel kan het besturingssysteem de VPN-app pauzeren om batterij te sparen. Als de app wordt hervat, is er een klein venster waarin de tunnel opnieuw wordt opgezet. Als de killswitch op OS-niveau is geïmplementeerd (via includeAllNetworks op iOS of always-on VPN op Android), is er geen lek. Als de killswitch puur in de app is geïmplementeerd, kan er een kort venster zijn waarbij het besturingssysteem apps heeft hervat maar de VPN nog niet opnieuw verbonden is, en apps die in dat venster netwerkverzoeken doen, zullen lekken.
Race bij opstarten
Op desktop is de periode tussen het opstarten en het starten van de VPN-client onbeschermd. Netwerk-bewuste apps die automatisch starten (Mail, Slack, Steam, systeemupdatecontroles) maken vaak verbindingen voordat de VPN actief is. Een robuuste killswitch installeert zijn firewallregel als een permanente opstarttijdregel, zodat zelfs bij het opstarten verkeer wordt geblokkeerd totdat de VPN verbinding maakt. De meeste consumenten-VPN-clients doen dit niet; de regel is alleen van toepassing nadat de client is gestart.
Killswitchtypes vergeleken
| Type | Wat het blokkeert | OS-ondersteuning | Veelvoorkomende faalscenario's |
|---|---|---|---|
| Systeembrede firewall | Al het niet-VPN-verkeer op kernelniveau | macOS, Windows, Linux; iOS via includeAllNetworks | IPv6-lekken als regels alleen IPv4 zijn; race bij opstarten; DNS-bootstrap-uitzondering |
| App-niveau (blokkeerlijst per app) | Alleen verkeer van vermelde apps | Windows, sommige macOS-clients | Apps die niet op de lijst staan blijven lekken; OS-componenten lekken; systeemservices lekken |
| Door OS afgedwongen always-on VPN | Al het verkeer op OS-niveau, ongeacht app-crash | Android (Altijd actieve VPN + Blokkeren zonder VPN), iOS (NetworkExtension on-demand) | Captive portal-inlog is geblokkeerd totdat je pauzeert; nauwelijks andere faalscenario's |
| Applicatiemonitor (de zwakke vorm) | Niets direct; sluit alleen opgegeven apps als VPN wegvalt | Sommige Windows-clients leveren dit nog steeds | Race tussen detectie en afsluiting lekt; eigenlijk geen killswitch |
Wat "always-on VPN" je biedt dat een killswitch op app-niveau niet biedt
Het belangrijkste onderscheid in 2026 is dat tussen door leveranciers geïmplementeerde killswitches en door het OS afgedwongen always-on VPN. Dit is waarom de door het OS afgedwongen versie wezenlijk sterker is:
- Overleeft crashes van de VPN-app. Als de VPN-app om welke reden dan ook crasht, gaat een killswitch op app-niveau daarmee mee. De firewallregel die hij heeft geïnstalleerd kan al dan niet blijven bestaan, afhankelijk van de implementatie. Een door het OS afgedwongen regel wordt door het besturingssysteem zelf vastgehouden en blijft van toepassing.
- Overleeft herstart. Veel killswitches op app-niveau installeren regels bij het starten van de app en verwijderen ze bij het afsluiten, waardoor er een gat is bij het opstarten. Instellingen voor always-on op OS-niveau worden gehonoreerd vanaf het eerste netwerkpakket dat het besturingssysteem na het opstarten routeert.
- Dekt systeemservices. Cloud-synchronisatie, controles op OS-updates, push-notificatiedaemons en andere OS-niveau-services gaan niet via de normale VPN-client-routing. Door het OS afgedwongen always-on dekt ze wel; een killswitch op app-niveau mogelijk niet.
- Kan niet per ongeluk worden omzeild door de gebruiker. Een killswitch op app-niveau heeft een schakelaar in de UI van de app. Een gebruiker (of een andere app met rechten) kan hem uitschakelen. Always-on op OS-niveau zit in systeeminstellingen en is moeilijker per ongeluk om te zetten.
Op Android: geef de voorkeur aan de door het OS afgedwongen versie — schakel "Altijd actieve VPN" en "Verbindingen zonder VPN blokkeren" in via de systeeminstellingen, en beschouw de eigen killswitch van de VPN-client als aanvulling. Op iOS: zoek naar VPN-clients die includeAllNetworks inschakelen; dat is de equivalente markering en biedt vergelijkbare garanties.
Wat Casper doet — het eerlijke antwoord
Casper's Cloak gebruikt een OS-geïntegreerde killswitch op elk platform — includeAllNetworks op iOS zodat het besturingssysteem zelf de no-leak-regel afdwingt, de always-on VPN-instellingen op Android, en pakketfilterregels op kernelniveau op macOS. Het gedrag is op alle drie hetzelfde: als de tunnel wegvalt, stopt al het verkeer, inclusief IPv6 en inclusief OS-niveau-services. Als de tunnel terugkomt, wordt het verkeer hervat. Er is geen schakelaar om te vergeten, geen lijst per app bij te houden, geen IPv6-uitzondering.
We combineren dit met bedreigingsbeveiliging en bedreigingsschild voor actief filteren tegen bekende schadelijke domeinen, zodat de tunnel niet alleen een routeringslaag is — hij verwerpt actief verbindingen met phishing, malware C2 en bekende slechte infrastructuur. De killswitch is de onderste garantielaag die ervoor zorgt dat niets de filtering omzeilt wanneer de tunnel kort wegvalt. Het gecombineerde effect: zelfs op vijandige netwerken zoals die worden besproken in onze analyse van aanvallen op openbare Wi-Fi, krijg je niet het "twee seconden onversleuteld"-venster dat een killswitch op uitsluitend app-niveau openlaat.
Ons standpunt over killswitches in het algemeen: het is een basisverwachting, geen premiumfunctie. Elke consumenten-VPN die in 2026 geen killswitch biedt, mist een fundamenteel veiligheidsmechanisme. Voor de achtergrond van dreigingsmodellering over waarom dit op systeemniveau belangrijk is, behandelt de NSA-richtlijn voor het selecteren en beveiligen van remote-access VPN's de architectuurredenering in detail, met een aanbeveling voor full-tunnel-architecturen ondersteund door handhaving op kernelniveau.
Conclusie
"Heeft deze VPN een killswitch" is de verkeerde vraag. De juiste vragen zijn: waar in de stack wordt de killswitch afgedwongen (app, systeem of besturingssysteem), dekt hij IPv6, blijft hij actief na app-crashes en herstarts, en staat hij standaard aan. Als de antwoorden "OS-niveau", "ja", "ja" en "ja" zijn, doet de killswitch zijn werk. Als de antwoorden "alleen app-niveau", "nee", "hangt ervan af" en "standaard uitgeschakeld" zijn, heb je een killswitch in naam maar niet in bescherming.
De eenvoudige praktijk: schakel op Android de always-on VPN op systeemniveau in met "Verbindingen zonder VPN blokkeren". Gebruik op iOS een VPN-client die includeAllNetworks inschakelt. Controleer op desktop na installatie door een lektest uit te voeren, koppel dan kort de verbinding aan de VPN-serverzijde los (of trek je netwerkkabel eruit) en bevestig dat het verkeer daadwerkelijk stopt. Als de lektest nog steeds je echte IP laat zien, werkt de killswitch niet zoals geadverteerd — onderzoek het voordat je het vertrouwt.