ZTNA vs site-to-site VPN: wat zero trust kan vervangen

ZTNA kan een site-to-site VPN vervangen voor alles wat mensen doen: gebruikers die applicaties openen, partners die één systeem nodig hebben, een pas overgenomen bedrijf dat in je ERP moet. Voor wat machines met elkaar doen kan het de tunnel niet vervangen: replicatie tussen domeincontrollers, monitoring die toestellen in filialen bevraagt, telefooncentrales, storagereplicatie en industrieel besturingsverkeer. De meeste organisaties met meer dan een handvol sites eindigen met beide, en de nuttige vraag is hoe klein de tunnel kan worden.

Dat onderscheid ontbreekt in de meeste vergelijkingen. Zoek op "ZTNA vs site-to-site VPN" en bijna elk resultaat vergelijkt een remote-access VPN-client op een laptop met een ZTNA-agent. Dat is een andere beslissing, die we behandelen in IPsec VPN versus ZTNA voor toegang op afstand. Dit artikel gaat over de tunnel tussen je gebouwen.

Wat elk van beide echt verbindt

Een site-to-site VPN verbindt netwerken. ZTNA verbindt een identiteit met een applicatie. Een tunnel tussen hoofdkantoor en filiaal laat de twee adresbereiken werken als één gerouteerd netwerk, zodat alles aan de ene kant alles aan de andere kant kan bereiken, tenzij een firewallregel dat tegenhoudt. ZTNA geeft een geverifieerde gebruiker, op een gecontroleerd toestel, toegang tot één benoemde applicatie en niets anders.

Site-to-site IPsec werkt op de netwerklaag. Het versleutelt IP-pakketten tussen twee gateways en vervoert wat erin zit, ook routeringsprotocollen wanneer de tunnel route-based is.

ZTNA werkt op de applicatielaag. In het model dat NIST beschrijft in SP 800-207 controleert een policy decision point elk verzoek en bemiddelt een enforcement point de sessie. In de praktijk staat er een connector naast de applicatie die een uitgaande verbinding opent naar de broker. Gebruikers krijgen nooit een adres op het doelnetwerk. Ze bereiken een gepubliceerde applicatie via haar naam, na controle van identiteit en toestel, en het netwerk erachter blijft onzichtbaar.

SD-WAN raakt er vaak tussen verzeild. Het is transport: versleutelde overlays over meerdere verbindingen, waarbij elke applicatie over het beste pad wordt gestuurd. Het levert nog altijd een gerouteerd netwerk tussen sites op en wordt pas een zero-trustontwerp wanneer er identiteitsgebaseerde toegang bovenop komt, zoals in een SASE-platform. De SD-WAN-gids behandelt de transportkant.

Bronnen: IETF RFC 4301 en RFC 7296 (IPsec en IKEv2), NIST SP 800-207 (Zero Trust Architecture).

Waar ZTNA een site-to-site tunnel niet kan vervangen

ZTNA kan geen verkeer dragen dat in het datacenter start en naar een toestel in een filiaal gaat, geen verkeer dat afhangt van broadcast of multicast, en geen protocollen die enkel over een gerouteerd pad werken. Daarmee valt een puur ZTNA-ontwerp af voor replicatie tussen domeincontrollers, centrale monitoring en scanning, bureautelefoons, printservers, storagereplicatie en het meeste industriële besturingsverkeer.

Projecten die alle tunnels in één keer schrappen, lopen hier vast, om één reden: een ZTNA-connector wacht op het verzoek van een gebruiker en routeert niet.

Verbindingen die de server start

Veel IT-beheer werkt van het centrum naar buiten. Configuration Manager die software naar toestellen in filialen pusht, Ansible dat SSH opent naar een hypervisor in een filiaal, een monitoringserver die een switch of een UPS via SNMP bevraagt: dat start allemaal op het hoofdkantoor en moet een privéadres in het filiaal bereiken. Een vulnerability scanner heeft rechtstreekse toegang op laag 3 en 4 nodig om hosts te herkennen en poorten af te tasten. Achter een ZTNA-broker ziet de scanner niets, waardoor het filiaal een blinde vlek wordt in je asset-inventaris.

Active Directory-replicatie

Domeincontrollers in filialen repliceren in beide richtingen met de kern via RPC, met de endpoint mapper op TCP 135 en een dynamisch hoog poortbereik (49152 tot 65535), naast Kerberos, LDAP en SMB. Beheerders die dit achter applicatieconnectoren plaatsten, melden replicatiefouten die af en toe opduiken. De gebruikelijke oplossingen zijn een afgeschermde tunnel die enkel verkeer tussen domeincontrollers draagt, of de overstap naar identiteit in de cloud.

Telefonie en printen

Wanneer een telefooncentrale op locatie een toestel in een filiaal laat rinkelen, start de PBX de SIP-sessie naar dat toestel, en de audio loopt over dynamisch onderhandelde UDP-poorten. Wie dat door een cloudbroker stuurt, voegt vertraging en jitter toe, en teams melden eenrichtingsaudio en verloren registraties. Printen heeft dezelfde vorm: printers maken zich bekend via multicast discovery, en een centrale printserver opent de verbinding naar de printer op TCP 9100 of 515.

Industriële en gebouwsystemen

PLC's, controllers en gebouwbeheersystemen spreken protocollen zoals Modbus/TCP, DNP3 en EtherNet/IP. Sommige, zoals PROFINET en EtherCAT, draaien rechtstreeks op Ethernet-frames. Deze toestellen kunnen geen agent draaien, hebben geen gebruikersidentiteit en spreken geen webprotocollen. Een SCADA-server die met controllers in het veld praat, heeft een stabiel gerouteerd pad nodig.

Bulkreplicatie

Nachtelijke back-ups en storagereplicatie verplaatsen grote volumes tussen sites. Hardware-IPsec verwerkt dat op lijnsnelheid; een cloudbroker voegt een bottleneck toe en soms kosten voor dataoverdracht.

Niets hiervan maakt ZTNA zwakker. Het maakt er een ander gereedschap van. De tunnel blijft waar machines met machines praten. Het punt is dat je hem niet meer voor al de rest gebruikt.

Waar de tunnel vervangen loont

De tunnel vervangen loont voor elke verbinding die een mens maakt. Gebruikerstoegang naar ZTNA verhuizen haalt het gerouteerde pad weg dat een aanvaller zou gebruiken om van een gecompromitteerde laptop in een filiaal naar je servers te gaan, haalt de VPN-gateway voor dat gebruik van het internet en maakt overlappende adresbereiken irrelevant.

Geen pad voor laterale beweging

Met een site-to-site tunnel kan een toestel in een filiaal dat ten prooi valt aan phishing de adresbereiken van het hoofdkantoor bereiken. Scans, ARP sweeps en exploitpogingen gaan door de tunnel zoals elk ander verkeer, en hypervisors, domeincontrollers en back-upservers liggen binnen bereik, tenzij de interne regels strak zijn. Met ZTNA komt het toestel in het filiaal nooit op het netwerk van het hoofdkantoor. Het bereikt de applicaties waar zijn gebruiker recht op heeft, en niets anders. De impact van één gecompromitteerde laptop krimpt tot die laptop en een handvol applicatiesessies. De gids over netwerksegmentatie behandelt de stap van VLAN's naar identiteitsgebaseerde isolatie.

Minder blootgestelde gateways

Perimetertoestellen die verbindingen vanaf het internet aanvaarden, behoren de laatste jaren tot de meest geviseerde systemen. De Known Exploited Vulnerabilities-catalogus van CISA bevat CVE-2024-3400 in GlobalProtect van Palo Alto, CVE-2024-21762 in de SSL VPN van FortiOS, CVE-2024-40766 in SonicOS van SonicWall, en de Cisco ASA-lekken die in de ArcaneDoor-campagne werden misbruikt. De meeste zitten in diensten voor toegang op afstand en beheer, niet in IPsec zelf, maar ze leven allemaal op hetzelfde toestel dat aan het internet hangt. Een ZTNA-connector opent geen inkomende poorten, dus in het filiaal valt er voor een scanner niets te vinden.

Geen gedeelde sleutels om te beheren

IPsec-meshes draaien op pre-shared keys of certificaten. Een sleutel die je in meerdere filialen hergebruikt, betekent dat één gelekte configuratieback-up de hele mesh blootlegt; certificaten lossen dat op, maar brengen vernieuwingen mee en het risico dat één verlopen certificaat tientallen tunnels platlegt. ZTNA gebruikt kortlevende credentials die aan je identity provider gekoppeld zijn en met één wijziging in te trekken zijn.

Fusies en partners

Twee bedrijven die allebei 192.168.1.0/24 gebruiken, kun je niet zomaar met een tunnel koppelen. Ze hebben NAT aan beide kanten nodig of een hernummeringsproject. ZTNA publiceert applicaties via naam, en de connector zet het adres om binnen zijn eigen netwerk, zodat overlappende bereiken er niet meer toe doen. Dezelfde logica geldt voor leveranciers: in plaats van een tunnel in je netwerk krijgt de partner één applicatie. Toegang voor derden zonder VPN werkt dat patroon uit.

Beslismatrix per scenario

Het juiste antwoord hangt af van wat er over de verbinding gaat. Deze matrix behandelt de zes situaties waar mid-market-teams het vaakst naar vragen.

Matrix gebaseerd op de architectuurpatronen in NIST SP 800-207 en het MEF 70-servicekader voor SD-WAN, en op ervaringen van beheerders uit migraties.

Vallen je sites in de tweede of vijfde rij, dan zie je het verschil het snelst door één interne applicatie via ZTNA te publiceren en de tunnel ernaast te laten draaien. Je kunt Jimber gratis proberen op één site.

Beheer en kosten

In de dagelijkse praktijk falen de twee modellen op een andere manier en kosten ze op andere plaatsen geld.

Pakketgrootte en vastgelopen transfers

IPsec voegt aan elk pakket ruwweg 50 tot 73 bytes aan headers toe, meer met NAT traversal, waardoor er in de tunnel een bruikbare grootte van ongeveer 1.420 tot 1.440 bytes overblijft. Wanneer een pakket op volle grootte met de don't-fragment-bit die grens raakt en een firewall het ICMP-bericht laat vallen dat dat zou moeten melden, krijg je het klassieke black hole: verbindingen gaan open, daarna blijven grote transfers hangen. De oplossing is MSS clamping op elke tunnelinterface. ZTNA-sessies lopen als gewone TLS- of QUIC-verbindingen, dus de eigen TCP-stack van het besturingssysteem regelt de pakketgrootte en dit soort fout komt voor gepubliceerde applicaties niet voor.

Rekeying en failover

IPsec-tunnels onderhandelen hun sleutels volgens een schema opnieuw. Pakketverlies of een drukke CPU tijdens een rekey kan beide kanten uit sync brengen tot dead peer detection de tunnel opnieuw opbouwt, en filialen met dynamische adressen hebben extra workarounds nodig. ZTNA-verbindingen zijn uitgaand, en transporten zoals QUIC kunnen een sessie van glasvezel naar 4G verplaatsen zonder nieuwe login.

Wat je ziet

Een IPsec-tunnel geeft je flows: adressen, poorten en volumes, die je dan met DHCP- en directorylogs moet correleren om een persoon te vinden. Een ZTNA-log registreert wie verbinding maakte, vanaf welk toestel, met welke applicatie. De keerzijde is minder troubleshooting hop per hop over het WAN.

Waar het geld naartoe gaat

Site-to-site-ontwerpen geven geld uit aan hardware: een firewall of router op elke site, vaak in paren, jaarlijkse supportcontracten en soms MPLS-circuits. Een cloudplatform verschuift die uitgave naar een abonnement, meestal per gebruiker, en laat filialen draaien op gewoon breedband met een lichter edge-toestel. Wat goedkoper is, hangt af van hoeveel sites je hebt, hoeveel gebruikers, en of er sowieso een vervanging aankomt. De besparing is het grootst waar dure private circuits kunnen verdwijnen; de kosten van een overstap weg van MPLS zet dat deel op een rij. Organisaties die firewalls in filialen vervangen die end of life zijn, zoals de Cisco Meraki MX64 en MX65, maken bij de vervanging dezelfde rekensom, zoals beschreven in Meraki MX end of support.

Wat NIS2 en CyFun verwachten rond segmentatie

NIS2 noch CyFun noemt een technologie. Beide verwachten dat je bepaalt welke systemen welke andere kunnen bereiken, dat je toegang beperkt tot wat nodig is, en dat je dat kunt aantonen.

Artikel 21 van NIS2 somt de maatregelen op die eronder vallen. Drie ervan raken rechtstreeks aan connectiviteit tussen sites: beveiliging van de toeleveringsketen, die bepaalt hoe partners je systemen bereiken; beleid rond cryptografie; en toegangscontrole. Een vlakke tunnel die een leverancier of een filiaal ruime toegang tot het hoofdkantoor geeft, valt moeilijk te rijmen met least privilege. Oude IKEv1-tunnels met zwakke ciphers en gedeelde sleutels vallen moeilijk te rijmen met een cryptografiebeleid. Onder artikel 20 keuren de bestuursorganen deze maatregelen goed, houden ze er toezicht op en kunnen ze aansprakelijk worden gesteld bij tekortkomingen.

In België vertaalt het CyberFundamentals (CyFun)-kader van het Centrum voor Cybersecurity België (CCB) die verplichtingen naar controles, en een certificering ertegen geeft een vermoeden van conformiteit met de Belgische NIS2-wet, die sinds 18 oktober 2024 van kracht is. De Protect-functie van CyFun omvat toegangscontrole en netwerkscheiding. In een audit vertaalt dat zich in concrete vragen: welk verkeer is toegelaten tussen sites, wie heeft de regels goedgekeurd, en waar staan de logs. Een any-any-regel over een site-to-site tunnel is een makkelijke vaststelling. Logs van identiteitsgebaseerde toegang die precies tonen wie welke applicatie bereikte, zijn sterk bewijs. Het migratieplan van VPN naar ZTNA beschrijft hoe je eerst de gebruikerstoegang verhuist en de infrastructuurtunnel als laatste aanpakt.

De argumenten om IPsec te houden

Een ervaren netwerkengineer zal drie goede argumenten voor de tunnel aanhalen.

"IPsec vervoert alles op lijnsnelheid." Klopt. Een tunnel maakt het niet uit wat erin zit, en firewalls met crypto-acceleratie versleutelen aan snelheden van meerdere gigabit met verwaarloosbare vertraging. ZTNA beëindigt sessies en controleert identiteit, en dat kost tijd en rekenkracht. Voor bulkreplicatie, grote bestandsoverdrachten tussen sites en alles wat gevoelig is voor latency is de tunnel het betere gereedschap. Daarom houdt het hybride ontwerp hem voor precies dat verkeer.

"Een tunnel tussen mijn eigen firewalls hangt van niemand af." Ook waar. Sleutels, routes en policies staan op je eigen apparatuur, en een storing bij een cloudbroker of identity provider raakt er niet aan. Verkeer tussen sites naar een cloudplatform verhuizen voegt een afhankelijkheid toe, en die verdient een echt antwoord: wat gebeurt er met elke applicatie als het platform onbereikbaar is. Voor gebruikerstoegang is het antwoord meestal aanvaardbaar, want gebruikers die SaaS openen, hangen al af van het internet en hun identity provider. Voor productieverkeer tussen machines is het dat vaak niet, wat opnieuw pleit voor een smalle tunnel.

"De helft van mijn toestellen kan geen agent draaien." Camera's, printers, badgelezers, gebouwcontrollers en PLC's hebben geen gebruiker en spreken geen webprotocollen. Een tunnel bereikt ze via hun IP-adres, zonder extra onderdelen. Ze achter ZTNA dwingen betekent jump hosts en reverse connectoren. De engineer heeft gelijk dat de tunnel hier het eenvoudigste gereedschap is. De onenigheid gaat enkel over de mensen: laptops, externe medewerkers en personeel op afstand hebben wel een identiteit, en hen een gerouteerd pad in het netwerk geven is het deel dat niet langer zinvol is.

Conclusie

ZTNA vervangt de site-to-site VPN niet. Het vervangt het meeste waarvoor de site-to-site VPN werd gebruikt. Houd een smalle, strak gefilterde tunnel of een SD-WAN-pad voor het verkeer tussen machines dat routering nodig heeft, en verhuis elke persoon, partner en elk overgenomen bedrijf naar identiteitsgebaseerde toegang. De tunnel wordt kleiner, het netwerk is niet langer vlak, en de gateway aan het internet verliest de meeste redenen om te bestaan.

De keuze hoeft ook geen twee leveranciers te betekenen. Jimber dekt SD-WAN tussen sites en ZTNA voor gebruikers op één Europees platform, zodat het hybride ontwerp vanuit één console draait. Probeer gratis met één site en één applicatie, of plan een demo om in kaart te brengen welke van je tunnels kleiner kunnen.

Veelgestelde vragen

Kan ZTNA een site-to-site VPN vervangen?

Niet volledig. ZTNA vervangt de tunnel voor toegang van gebruikers tot applicaties, toegang voor partners en de meeste toegang tot cloudapplicaties. Het kan geen verkeer dragen dat de server start, geen diensten die op broadcast steunen, geen replicatie tussen domeincontrollers, geen telefonie en de meeste industriële protocollen niet, want die hebben een gerouteerd pad nodig. De meeste organisaties met meerdere sites eindigen met een hybride ontwerp.

Wat is het belangrijkste verschil tussen ZTNA en een site-to-site VPN?

Een site-to-site VPN koppelt twee netwerken op laag 3, zodat toestellen aan beide kanten elkaar kunnen bereiken, tenzij regels dat blokkeren. ZTNA verbindt een geverifieerde gebruiker op een gecontroleerd toestel met één specifieke applicatie op laag 7, terwijl het netwerk erachter onzichtbaar blijft.

Waarom is een site-to-site VPN een beveiligingsrisico?

Het creëert een gerouteerd pad tussen locaties. Als één toestel in een filiaal gecompromitteerd raakt, kan een aanvaller via de tunnel systemen op het hoofdkantoor scannen en aanvallen, tenzij de interne regels strikt zijn. De gateway moet bovendien verbindingen vanaf het internet aanvaarden, wat hem op zich al een doelwit maakt.

Hoe voorkomt ZTNA laterale beweging tussen filialen?

Het toestel van de gebruiker krijgt nooit een adres op het doelnetwerk. Het kan enkel de applicaties bereiken waar zijn gebruiker recht op heeft, via verbindingen die de broker bemiddelt. Andere subnetten, servers en toestellen zijn vanaf dat toestel niet routeerbaar, dus scans en exploitpogingen vinden niets om te bereiken.

Wat gebeurt er met printers en bureautelefoons bij de overstap naar ZTNA?

Ze werken vaak niet meer in een puur ZTNA-ontwerp, omdat ze steunen op broadcast discovery, dynamische UDP-poorten en verbindingen die bij de server starten. Houd ze op aparte, lokaal gerouteerde en gefilterde netwerksegmenten, of stap over op cloudprinten en een telefooncentrale in de cloud.

Hoe houden we Active Directory-replicatie werkend zonder volledige tunnel?

Houd een smalle, route-based tunnel die enkel verkeer tussen domeincontrollers op de vereiste poorten toelaat, of verhuis de filialen naar identiteit in de cloud. Applicatieconnectoren zijn geen betrouwbaar pad voor multi-masterreplicatie over dynamische RPC-poorten.

Hoe gaat ZTNA om met overlappende IP-adresbereiken?

Applicaties worden via naam gepubliceerd, en de connector zet het adres om binnen zijn eigen netwerk. Twee organisaties kunnen intern allebei 10.1.1.0/24 gebruiken zonder conflict, wat NAT aan beide kanten of een hernummeringsproject tijdens een fusie vermijdt.

Heeft een ZTNA-connector open inkomende poorten nodig?

Nee. Een site-to-site gateway luistert op UDP 500 en 4500. Een ZTNA-connector maakt uitgaande versleutelde verbindingen naar de broker, meestal over poort 443, zodat de site geen luisterende dienst blootstelt die internetscanners kunnen vinden.

Kan SD-WAN ZTNA vervangen voor de beveiliging van filialen?

Nee. SD-WAN is een transporttechnologie. Het kiest de beste verbinding en versleutelt verkeer tussen sites, maar levert nog altijd een gerouteerd netwerk op met hetzelfde risico op laterale beweging. Het wordt pas een beveiligingsontwerp in combinatie met identiteitsgebaseerde toegang, webbeveiliging en firewalling in een SASE-platform.

Hoe geven we een onderhoudsleverancier toegang tot productiesystemen zonder tunnel?

Plaats een ZTNA-connector naast een jump host in een aparte zone. De leverancier meldt zich aan met multifactorauthenticatie, bereikt via de broker enkel die jump host en beheert de controllers van daaruit. Er bestaat geen netwerkpad tussen de leverancier en het productienetwerk.