Wat zijn de beveiligingsrisico’s van VPN split tunnelling?
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.
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.
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 audit.
Wat is split tunnelling en waarom gebruiken IT-teams het?
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.
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.
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.
Het nadeel: je verliest het overzicht over alles wat direct gaat.
De beveiligingsrisico’s die IT-teams onderschatten
Split tunnelling creëert 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.
DNS-lek stelt uw interne infrastructuur bloot
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.
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 behandelt deze aanvalsvector in detail.
Malware komt binnen via het onbeveiligde pad
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.
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.
Exfiltratie van gegevens via directe internetverbindingen
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.
Het legacy VPN-risicorapport laat zien hoe zijwaartse beweging na de initiële compromittering van het VPN het dominante aanvalspatroon is geworden in ransomware-incidenten in de Benelux.
Gecompromitteerde thuisnetwerken worden een brug
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.
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.
Waar split tunnelling conflicteert met NIS2
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.
Artikel 21, lid 2, onder a): risicoanalyse en beleid voor de beveiliging van informatiesystemen. 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.
Artikel 21, lid 2, onder e): beveiliging bij aankoop, ontwikkeling en onderhoud van netwerk- en informatiesystemen. 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 tijdlijn laat zien hoe snel de industrie afstand neemt van legacy toegang op afstand.
Artikel 21, lid 2, onder g): elementaire cyberhygiënepraktijken en cyberveiligheidstraining. NIS2 verwijst expliciet naar Zero Trust principes als onderdeel van goede cyberhygiëne. 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.
Artikel 21, lid 2, onder i): toegangscontrolebeleid. 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.
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ëert het negeren van deze richtlijnen een direct nalevingsgat.
Hoe CyFun-niveaus VPN-configuratie in België aanpakken
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.
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.
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ëert blinde vlekken in de verkeersbewaking.
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 wordt uitgelegd wat beoordelaars verwachten.
Organisaties die CyFun-verificatie nastreven, zullen merken dat een geconsolideerd beveiligingsplatform veel efficiënter het bewijsmateriaal genereert dat auditors nodig hebben dan een gefragmenteerde stapel met VPN-uitzonderingen die in spreadsheets zijn gedocumenteerd.
Hoe ZTNA het dilemma van gesplitste tunnels elimineert
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.
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.
ZTNA van Jimber vervangt de tunnel volledig. Gebruikers maken verbinding met de applicaties die ze nodig hebben, geverifieerd door identiteits- en apparaatstatuscontroles, 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.
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.
Voor IT-managers die de VPN-naar-ZTNA migratie uitvoeren, verdwijnt de vraag over de gesplitste tunneling op dag één van de pilot. De eerste applicaties die via ZTNA worden gepubliceerd, profiteren onmiddellijk van granulaire toegang en volledige logging, terwijl legacy VPN-toegang parallel kan blijven draaien totdat de migratie is voltooid.
Veelgestelde vragen
Is gesplitste tunneling ooit acceptabel onder NIS2?
NIS2 verbiedt split tunnelling niet expliciet bij naam. De technische implementatierichtlijnen van ENISA raden echter aan om het uit te schakelen of te beperken en de vereisten van Artikel 21 voor toegangscontrole, risicobeheer en verkeersmonitoring zijn moeilijk na te leven als een deel van het eindpuntverkeer onzichtbaar is voor uw beveiligingspakket. Als u gesplitste tunneling handhaaft, verwacht dan een gedetailleerde risicobeoordeling die de uitzondering rechtvaardigt.
Raadt Microsoft nog steeds gesplitste tunneling aan voor Teams?
Microsofts oorspronkelijke richtlijn voor gesplitste tunneling uit 2020 was een reactie op de beperkte VPN-capaciteit tijdens de pandemie. De aanbeveling was specifiek voor Teams mediaverkeer, dat al versleuteld is op de applicatielaag. Microsoft heeft sindsdien functies geïntroduceerd zoals Global Secure Access die verkeer door cloud beveiligingscontroles leiden zonder dat hiervoor traditionele VPN split tunnelling nodig is. De workaround uit de tijd van de pandemie is niet langer de enige optie.
Hoe gaat ZTNA anders om met Microsoft 365-verkeer dan met VPN met gesplitste tunnel?
Met VPN met gesplitste tunnel gaat M365-verkeer rechtstreeks naar Microsoft-servers zonder enige beveiligingsinspectie. Met ZTNA en een cloud-native SWG gaat M365-verkeer nog steeds rechtstreeks (geen backhaul via een centrale gateway), maar het passeert beleidshandhaving die controleert op gegevensverlies, malware en compliance-overtredingen. Dezelfde prestaties, een andere beveiligingshouding.
Kan ik gesplitste tunneling uitschakelen zonder de prestaties te verlagen?
Niet met een traditioneel VPN. Volledige tunnelconfiguraties dwingen al het verkeer door de concentrator, wat latentie toevoegt en een bandbreedtebottleneck creëert. Daarom is ZTNA het praktische antwoord: het elimineert de noodzaak voor een tunnel helemaal, dus er is geen prestatieverlies te vermijden. In de vergelijking IPsec VPN vs ZTNA worden de prestatieverschillen uitgesplitst.
Wat moet ik als eerste controleren als ik momenteel gesplitste tunneling gebruik?
Begin met DNS-configuratie. Controleer of uw gesplitste tunneleindpunten bedrijfs-DNS of lokale resolvers gebruiken. Als DNS queries naar lokale resolvers lekken, is uw interne netwerkstructuur blootgesteld. Controleer vervolgens welke applicaties zijn uitgesloten van de tunnel en beoordeel of er applicaties zijn die gevoelige gegevens verwerken. Documenteer deze bevindingen, want een CyFun-beoordelaar zal hierom vragen.
Hoe snel kan ik migreren van split tunnel VPN naar ZTNA?
Een gefaseerde aanpak is gebruikelijk. Publiceer eerst twee of drie applicaties met een laag risico via ZTNA, valideer de gebruikerservaring en breid vervolgens de dekking applicatie voor applicatie uit. De meeste organisaties in het middensegment voltooien de migratie binnen enkele weken, niet maanden. VPN en ZTNA draaien parallel tijdens de overgang, dus er is geen big-bang overgang.
Klaar om het gat in de gesplitste tunneling te dichten vóór je CyFun-deadline? Boek een demo en zie hoe Jimber gedeeltelijke VPN-bescherming vervangt door ZTNA met volledige zichtbaarheid in één cloud-beheerd platform.
