Split tunnelling leidt een deel van het verkeer door het VPN en stuurt de rest rechtstreeks naar het internet. Dit brengt vier risico’s met zich mee: DNS-lekken die interne hostnamen blootleggen, levering van malware via het onbeschermde pad, gegevensdiefstal via directe internetverbindingen en gecompromitteerde thuisnetwerken die overbruggen naar bedrijfssystemen. Onder NIS2 zijn deze blinde vlekken in strijd met de vereisten van Artikel 21 voor toegangscontrole en risicobeheer. ZTNA elimineert het dilemma volledig door de tunnel te vervangen door identiteitsgebaseerde toegang per applicatie. <\/p>\n
Gesplitste tunneling begon als een oplossing voor de prestaties. Tijdens de pandemie bezweken VPN-concentrators onder het gewicht van volledige tunnelconfiguraties en Microsoft raadde aan om het Teams-verkeer om de tunnel heen te leiden om de latentie te verminderen. Dat advies was logisch toen de prioriteit lag bij het draaiende houden van videogesprekken. Het heeft minder zin nu NIS2 auditors gerichte vragen stellen over de zichtbaarheid van verkeer en toegangscontrole. <\/p>\n
Het probleem is eenvoudig. Elk pakket dat je VPN omzeilt, omzeilt ook je beveiligingspakket. Geen firewall inspectie, geen web gateway filtering, geen DLP controles. Voor IT-managers die nog steeds met gesplitste tunnelconfiguraties werken, is de vraag niet langer of dit risico’s met zich meebrengt. Dat doet het wel. De vraag is of je die configuratie kunt verdedigen tijdens een NIS2 compliance checklist<\/a> audit. <\/p>\n Split tunneling verdeelt het netwerkverkeer op het eindpunt. Sommige pakketten reizen door de versleutelde VPN-tunnel naar de bedrijfspoort. De rest gaat rechtstreeks naar het internet via de lokale verbinding van de gebruiker. <\/p>\n Er zijn drie veel voorkomende configuraties. Volledige tunnel stuurt alles door het VPN, waardoor het beveiligingsteam volledig inzicht heeft, maar de latentie toeneemt en de bandbreedte onder druk komt te staan. Gesplitste tunnel (inclusief) stuurt alleen verkeer dat bestemd is voor specifieke IP-bereiken van het bedrijf door het VPN, terwijl al het andere verkeer rechtstreeks gaat. Invers gesplitste tunnel (op basis van uitsluiting) stuurt alles door het VPN behalve expliciet uitgesloten bestemmingen zoals Microsoft 365 of Zoom. <\/p>\n IT-teams maken gebruik van gesplitste tunneling om praktische redenen. Volledige tunnelconfiguraties backhaul cloud-gebonden verkeer via een centrale gateway, waardoor latentie wordt toegevoegd die de kwaliteit van videogesprekken ondermijnt en SaaS-toepassingen vertraagt. Wanneer een in Brussel gevestigde werknemer Microsoft 365-servers in Amsterdam moet bereiken, is het verspilling om dat verkeer eerst door een VPN-concentrator in Antwerpen te leiden. Split tunnelling lost het prestatieprobleem op. <\/p>\n Het nadeel: je verliest het overzicht over alles wat direct gaat.<\/p>\n Split tunnelling cre\u00ebert een dual-homed eindpunt. Het apparaat bevindt zich zowel op het bedrijfsnetwerk (via VPN) als op het lokale netwerk van waaruit de gebruiker verbinding maakt. Die combinatie is de oorzaak van elk risico hieronder. <\/p>\n Wanneer split tunnelling actief is, worden DNS-query’s voor niet-bedrijfsbestemmingen vaak opgelost via de DNS-server van het lokale netwerk in plaats van de bedrijfsresolver. Dit lekt interne hostnamen en onthult de structuur van je netwerk aan iedereen die dat lokale DNS-verkeer controleert. <\/p>\n Een gecompromitteerde thuisrouter kan dit verder uitbuiten door DNS-kaping, waarbij de gebruiker wordt omgeleid naar een vervalste aanmeldpagina voor bedrijfsdiensten. Omdat het verzoek buiten de VPN-tunnel wordt verzonden, krijgt geen van je beveiligingscontroles het te zien. De gebruiker voert zijn gegevens in op een pagina die er als legitiem uitziet en de aanvaller buit ze uit. Onze gids DNS-beveiliging in Zero Trust<\/a> behandelt deze aanvalsvector in detail. <\/p>\n Een gebruiker die buiten de tunnel op het web surft downloadt een kwaadaardig bestand. De Secure Web Gateway van het bedrijf ziet dit nooit omdat het verkeer de VPN volledig omzeilt. Zodra de malware wordt uitgevoerd, heeft het twee opties: gegevens direct exfiltreren via de onbeveiligde internetverbinding, of via de actieve VPN-tunnel het bedrijfsnetwerk binnendringen. <\/p>\n Het tweede scenario is gevaarlijk. De VPN-tunnel is geverifieerd en vertrouwd. Malware die gebruik maakt van die tunnel ziet eruit als legitiem intern verkeer. Beveiligingsteams die de VPN concentrator in de gaten houden, zien normaal uitziende verbindingen van een vertrouwde gebruiker, terwijl de aanvankelijke inbreuk geheel buiten hun gezichtsveld plaatsvond. <\/p>\n Elke toepassing die buiten de tunnel draait, kan gegevens rechtstreeks naar het internet sturen zonder langs DLP-controles te komen. Een gebruiker die gevoelige bestanden kopieert naar een persoonlijke cloudopslagaccount, een gecompromitteerde browserextensie die sessietokens uploadt, een keylogger die referenties verstuurt naar een command-and-control server, dit gebeurt allemaal onzichtbaar wanneer split tunnelling actief is. <\/p>\n Het legacy VPN-risicorapport<\/a> laat zien hoe zijwaartse beweging na de initi\u00eble compromittering van het VPN het dominante aanvalspatroon is geworden in ransomware-incidenten in de Benelux.<\/p>\n VPN-apparaten op thuisnetwerken delen dat netwerk met smart TV’s, IoT-apparaten, spelcomputers voor kinderen en andere eindpunten met minimale beveiliging. Een aanvaller die een apparaat op het thuisnetwerk compromitteert, kan mogelijk de met VPN verbonden werklaptop bereiken. <\/p>\n Met split tunnelling actief kan de aanvaller de werklaptop als bridge gebruiken. Verkeer van het gecompromitteerde thuisnetwerk bereikt de bedrijfsomgeving via de geauthenticeerde VPN-tunnel. Het ransomware-incident in het ziekenhuis van AZ Monica in januari 2026 illustreerde hoe kwetsbaar gezondheidszorgnetwerken blijven als externe toegangsarchitecturen dit soort laterale overbrugging toestaan. <\/p>\n In artikel 21, lid 2, van NIS2 worden de minimale cyberbeveiligingsmaatregelen opgesomd die organisaties moeten implementeren. Split tunnelling is in strijd met ten minste vier van deze vereisten. <\/p>\n Artikel 21, lid 2, onder a): risicoanalyse en beleid voor de beveiliging van informatiesystemen.<\/strong> U kunt geen adequate risicoanalyse uitvoeren op verkeer dat u niet kunt zien. Split tunnelling leidt opzettelijk een deel van het eindpuntverkeer buiten uw bewakingsperimeter. Een auditor zal vragen welk percentage van het verkeer van uw externe gebruikers uw beveiligingsmaatregelen omzeilt. Als het antwoord iets meer dan nul is, hebt u een gedocumenteerde rechtvaardiging nodig. <\/p>\n Artikel 21, lid 2, onder e): beveiliging bij aankoop, ontwikkeling en onderhoud van netwerk- en informatiesystemen.<\/strong> Het draaien van VPN-infrastructuur met bekende architecturale zwakheden, wanneer de verkopersgemeenschap deze zwakheden algemeen heeft erkend en alternatieven heeft aangeboden, is moeilijk te verdedigen als een proportionele maatregel. De SSL VPN deprecated across vendors<\/a> tijdlijn laat zien hoe snel de industrie afstand neemt van legacy toegang op afstand. <\/p>\n Artikel 21, lid 2, onder g): elementaire cyberhygi\u00ebnepraktijken en cyberveiligheidstraining.<\/strong> NIS2 verwijst expliciet naar Zero Trust principes als onderdeel van goede cyberhygi\u00ebne. Split tunnelling werkt op basis van impliciet vertrouwen: als de tunnel eenmaal tot stand is gebracht, worden beslissingen over het routeren van verkeer genomen zonder voortdurende verificatie. Dat is het tegenovergestelde van Zero Trust. <\/p>\n Artikel 21, lid 2, onder i): toegangscontrolebeleid.<\/strong> VPN’s verlenen meestal toegang op subnetniveau na authenticatie. Split tunnelling voegt een extra laag van zwakte toe door eindpunten toe te staan om ongecontroleerde verbindingen te onderhouden naast die al brede toegang. Auditors verwachten handhaving van de minst geprivilegieerde, geen architecturale uitzonderingen die het aanvalsoppervlak vergroten. <\/p>\n De technische implementatieleidraad van ENISA, die in juni 2025 is gepubliceerd ter ondersteuning van Uitvoeringsverordening (EU) 2024\/2690, gaat rechtstreeks in op de beveiliging van externe toegang. De leidraad beveelt aan dat entiteiten gesplitste tunneling voor externe toegang uitschakelen of beperken, op basis van het feit dat al het verkeer van externe apparaten door de beveiligingscontroles van de organisatie moet lopen. Voor entiteiten in NIS2-gereguleerde sectoren cre\u00ebert het negeren van deze richtlijnen een direct nalevingsgat. <\/p>\n Het Belgische CyberFundamentals (CyFun)-raamwerk vertaalt NIS2 in praktische controles. De deadline van april 2026 voor het indienen van zelfevaluaties bij de CCB betekent dat VPN-configuraties nu onder de loep worden genomen. <\/p>\n Op CyFun Basic niveau moeten organisaties aantonen dat toegang op afstand geverifieerd en versleuteld is. Split tunnelling is niet inherent in strijd met deze eis, maar de documentatielast neemt toe omdat je moet rechtvaardigen waarom bepaald verkeer wordt uitgesloten van versleuteling en inspectie. <\/p>\n Op CyFun Important en Essential niveau worden de eisen strenger. Toegangscontrolemaatregelen moeten de principes van de minst geprivilegieerde volgen en het netwerkverkeer moet worden gecontroleerd op afwijkingen. Split tunnelling ondermijnt beide: het verleent bredere toegang dan nodig is door ongecontroleerde internetverbindingen naast bedrijfstoegang toe te staan en het cre\u00ebert blinde vlekken in de verkeersbewaking. <\/p>\n De CyFun Protect functiecontroles (PR.AC-3, PR.AC-4) vereisen gedocumenteerd bewijs dat de toegang beperkt is tot wat elke rol nodig heeft. Een VPN-configuratie die gesplitste tunneling toestaat is moeilijker te documenteren als conform, omdat u opzettelijk verkeer uitsluit van uw controleraamwerk. In de CyFun zelfevaluatiegids<\/a> wordt uitgelegd wat beoordelaars verwachten. <\/p>\n Organisaties die CyFun-verificatie nastreven, zullen merken dat een geconsolideerd beveiligingsplatform veel effici\u00ebnter het bewijsmateriaal genereert dat auditors nodig hebben dan een gefragmenteerde stapel met VPN-uitzonderingen die in spreadsheets zijn gedocumenteerd.<\/p>\n Het gesplitste tunneldebat bestaat vanwege een VPN-beperking: de tunnel is alles-of-niets op netwerkniveau, dus je routeert ofwel alles er doorheen (traag) of je zondert wat verkeer uit (riskant). ZTNA verwijdert de tunnel volledig, waardoor het dilemma irrelevant wordt. <\/p>\n Met ZTNA hoeft er geen tunnel gesplitst te worden. Gebruikers maken direct verbinding met de specifieke applicaties waartoe ze geautoriseerd zijn, geverifieerd aan de hand van identiteit en apparaatstatus bij elk verzoek. Verkeer naar cloudapplicaties zoals Microsoft 365 gaat direct zonder omweg door een centrale gateway, maar het gaat nog steeds door een cloud-native Secure Web Gateway die het beleid inspecteert en afdwingt. U krijgt het prestatievoordeel van directe toegang en het beveiligingsvoordeel van volledige zichtbaarheid. Geen compromis nodig. <\/p>\n ZTNA van Jimber vervangt de tunnel volledig. Gebruikers maken verbinding met de applicaties die ze nodig hebben, geverifieerd door identiteits- en apparaatstatuscontroles<\/a>, zonder al het verkeer door een centrale gateway te leiden. Er is geen VPN-concentrator die op het openbare internet luistert, dus er is geen doelwit voor poortscanning of zero-day-exploitatie. Elke applicatieverbinding is individueel geautoriseerd. Zelfs als een apparaat gecompromitteerd is door een lokale netwerkaanval, kan de aanvaller niet doorschakelen naar andere systemen omdat die systemen onzichtbaar en onbereikbaar zijn. <\/p>\n SWG van Jimber inspecteert al het webverkeer, ongeacht de locatie van de gebruiker, en dicht zo de zichtbaarheidskloof die ontstaat door gesplitste tunneling. Elk toegangsverzoek wordt gelogd met de identiteit van de gebruiker, apparaatstatus, toepassingsdoel en beleidsbeslissing. Dat is precies het controlespoor dat NIS2-beoordelaars verwachten, en het wordt automatisch gegenereerd in plaats van handmatig samengesteld uit meerdere tools. <\/p>\nWat is split tunnelling en waarom gebruiken IT-teams het?<\/h2>\n
De beveiligingsrisico’s die IT-teams onderschatten<\/h2>\n
DNS-lek stelt uw interne infrastructuur bloot<\/h3>\n
Malware komt binnen via het onbeveiligde pad<\/h3>\n
Exfiltratie van gegevens via directe internetverbindingen<\/h3>\n
Gecompromitteerde thuisnetwerken worden een brug<\/h3>\n
Waar split tunnelling conflicteert met NIS2<\/h2>\n
Hoe CyFun-niveaus VPN-configuratie in Belgi\u00eb aanpakken<\/h2>\n
Hoe ZTNA het dilemma van gesplitste tunnels elimineert<\/h2>\n