Site-to-site VPN opzetten: van ontwerp tot livegang

Een site-to-site VPN is een versleutelde tunnel tussen twee netwerken, opgebouwd via IPsec en IKE, waarmee kantoren, datacenters of clouds veilig met elkaar praten alsof ze op één lokaal netwerk zitten. Je gebruikt hem voor kantoor-naar-kantoor koppelingen, hybride cloudverbindingen of als goedkope failover naast een private circuit. Voor nieuwe implementaties is de aanbevolen basis IKEv2 met een route-based (VTI) opzet, omdat die combinatie het beste schaalt en het makkelijkst te onderhouden is.

Kort samengevat:

• Een route-based VPN (VTI) schaalt beter en is bij intranetverbindingen de voorkeurskeuze, terwijl policy-based VPN vooral geschikt is voor beperkte externe verbindingen.
• Voor nieuwe implementaties is IKEv2 met AES-GCM-256 en ECDH-groepen 19, 20 of 21 de aanbevolen standaard voor sterke beveiliging en betere prestaties.
• Bij meer dan drie locaties of veranderlijke netwerken is BGP over de VPN de beste keuze voor automatische route-uitwisseling en schaalbaarheid.
• Het correct plannen van adressen, firewalls, NAT-regels en authenticatiemethode vooraf voorkomt veelvoorkomende problemen en onnodige herconfiguraties.
• Uitbesteden aan gespecialiseerde partijen bespaart tijd, vermindert risico’s en zorgt voor een gestructureerde aanpak, vooral bij grote of complexe netwerken.

Inhoudsopgave

• Wat is een site-to-site VPN en welke typen bestaan er
• Wanneer kies je site-to-site VPN en wat zijn de alternatieven
• Technische basis: protocollen, algoritmes en moderne aanbevelingen
• Voorbereiding en prerequisites vóór configuratie
• Stapsgewijze setup checklist voor een site-to-site VPN
• Routing, hoge beschikbaarheid en schaal
• Beveiligings- en hardeningpraktijken
• Performance tuning en veelvoorkomende valkuilen
• Troubleshooting checklist: snelle controles en commando’s
• Praktijkperspectief van NLXS: wanneer uitbesteden slim is
• Ontwerpkeuzes die vandaag nog stand houden
• Site-to-site VPN uitbesteden aan NLXS
• Bronnen
• Veelgestelde vragen

Wat is een site-to-site VPN en welke typen bestaan er

Een site-to-site VPN koppelt twee netwerken via gateway-apparaten die aan beide kanten een tunnel opzetten. Dat kan een firewall, router of cloud-gateway zijn. Binnen die tunnel wordt verkeer versleuteld met IPsec, terwijl IKE de sleuteluitwisseling regelt. Het resultaat: twee kantoren, of een kantoor en een cloudnetwerk, gedragen zich netwerktechnisch als buren, ook al liggen ze honderden kilometers uit elkaar.

De architectuur bestaat uit drie kernonderdelen: de gateway-endpoints aan beide zijden, de tunnel zelf, en de traffic selectors die bepalen welk verkeer überhaupt de tunnel in mag. Die laatste twee bepalen ook het onderscheid tussen de twee hoofdtypen VPN-ontwerp.

• Policy-based VPN: je definieert expliciete regels (welke bron-IP naar welke bestemming-IP) die bepalen wat versleuteld wordt. Werkt goed bij een klein, stabiel aantal subnets.
• Route-based VPN (VTI): je maakt een virtuele tunnelinterface en laat de routingtabel bepalen wat er doorheen gaat. Dit schaalt beter, want je voegt simpelweg een route toe in plaats van een nieuwe policy.

Voor intranetgebruik, waarbij twee vestigingen van hetzelfde bedrijf koppelen, is route-based vrijwel altijd de betere keuze. Bij extranetscenario’s, waarbij je slechts een paar specifieke subnets met een externe partner deelt, kan policy-based nog steeds logisch zijn, simpelweg omdat de scope bewust beperkt moet blijven. De hybride VPN-architectuur van Azure laat goed zien hoe route-based ontwerpen zich verhouden tot BGP en active-active gateways in een cloudcontext.

Wanneer kies je site-to-site VPN en wat zijn de alternatieven

Site-to-site VPN is de standaardoplossing zodra je twee vaste locaties structureel wilt verbinden zonder een dure private lijn te huren. Denk aan filiaalconnectiviteit tussen hoofdkantoor en winkels, hybride cloudopstellingen waarbij een on-premises datacenter met een virtueel netwerk in de cloud praat, of extranets met een vaste zakenpartner. Veel bedrijven zetten de VPN ook in als backup naast een dedicated verbinding zoals ExpressRoute of Direct Connect, zodat een storing op de private lijn niet meteen de hele verbinding platlegt.

Toch is site-to-site niet altijd de beste keuze:

• SD-WAN is efficiënter als je tientallen locaties met wisselende bandbreedtebehoeften moet verbinden en centraal beleid wilt afdwingen.
• Remote access VPN past beter bij individuele medewerkers die vanaf een laptop thuis of onderweg inloggen, niet bij netwerk-naar-netwerk verkeer.
• Dedicated circuits zijn te verantwoorden zodra latency of bandbreedtegaranties bedrijfskritisch zijn en de kosten daarvoor opwegen tegen het risico van een gedeelde internetverbinding.

De operationele impact groeit met het aantal tunnels. Bij twee of drie locaties beheer je dat met de hand. Bij twintig of meer wordt monitoring, certificaatbeheer en tunnelbewaking een taak die automatisering en gestructureerde documentatie vereist, anders verzand je in ad-hoc troubleshooting.

Technische basis: protocollen, algoritmes en moderne aanbevelingen

IKEv2 is de standaard voor nieuwe implementaties. Het protocol is sneller in het herstellen van een tunnel na verbindingsverlies, ondersteunt betere mobiliteit tussen IP-adressen en kent robuustere NAT-Traversal-mechanismen dan zijn voorganger. RFC 7296 beschrijft die IKEv2-processen in detail, inclusief hoe SA’s worden opgebouwd en onderhouden. IKEv1 zet je alleen nog in als een legacy-apparaat aan de andere kant simpelweg niets anders spreekt.

Voor de versleuteling zelf is AES-GCM-256 de voorkeurscipher. GCM combineert versleuteling en integriteitscontrole in één bewerking, wat sneller is dan een aparte hash-functie erna en minder overhead geeft op de CPU van je gateway. Voor de sleuteluitwisseling kies je een moderne Diffie-Hellman-groep: DH-groep 19, 20 of 21 (elliptische curven) bieden sterkere beveiliging bij lagere rekenkosten dan de oudere modulaire groepen. Perfect Forward Secrecy (PFS) zet je altijd aan, zodat het compromitteren van één sessiesleutel niet meteen historisch verkeer blootlegt.

Wat betreft levensduur van Security Associations: kortere lifetimes verhogen de beveiliging maar verhogen ook de kans op korte onderbrekingen tijdens rekeying. Een gangbare balans is 8 uur voor Phase 1 en 1 uur voor Phase 2, aan te passen aan het risicoprofiel van de verbinding.

Voor authenticatie is de keuze tussen een pre-shared key (PSK) en certificaten vooral een kwestie van schaal. Bij twee of drie tunnels is een PSK snel op te zetten. Zodra je richting tientallen tunnels of een omgeving met strengere compliance-eisen gaat, is certificaatgebaseerde authenticatie te verantwoorden, ondanks de extra beheerlast van een PKI. NAT-Traversal (NAT-T) tot slot is nodig zodra een van beide gateways achter een NAT-apparaat zit; het verpakt IKE- en ESP-verkeer in UDP zodat het door adresvertaling heen komt zonder de integriteit te breken.

Voorbereiding en prerequisites vóór configuratie

Een tunnel die halverwege de implementatie moet worden herconfigureerd, kost meer tijd dan een gedegen voorbereiding vooraf. Loop deze punten langs voordat je één regel configuratie schrijft:

1. Adresruimte plannen. Controleer dat de subnets aan beide kanten niet overlappen. Overlappende ranges zijn de meest voorkomende reden dat een tunnel wel opkomt maar geen verkeer doorlaat.
2. Public IP’s vastleggen. Beide gateways hebben een stabiel, publiek bereikbaar IP-adres nodig, of in cloudomgevingen een gereserveerd gateway-adres.
3. Firewallregels en poorten openen. UDP 500 voor IKE, UDP 4500 voor NAT-T, en het ESP-protocol (protocolnummer 50) moeten in beide richtingen worden toegelaten op elke tussenliggende firewall.
4. NAT-bypass regels instellen. Verkeer dat de tunnel in gaat, mag niet eerst door een NAT-regel worden vertaald, anders klopt de traffic selector niet meer.
5. Authenticatiemethode en sleutelbeheer bepalen. Kies PSK of certificaten en leg vast wie verantwoordelijk is voor rotatie.
6. Monitoring en QoS inrichten. Bepaal vooraf hoe je tunnelstatus bewaakt en of bepaald verkeer (bijvoorbeeld VoIP) prioriteit moet krijgen binnen de tunnel.

Sla deze checklist niet over, ook niet bij “even snel een testtunnel”. De meeste productieproblemen die wij bij klanten tegenkomen, herleiden we tot een van deze zes punten.

Stapsgewijze setup checklist voor een site-to-site VPN

Deze volgorde werkt vendor-neutraal, of je nu met een Cisco-router, een MikroTik-apparaat of een cloudgateway van Azure of AWS werkt.

1. Definieer subnets en peer-IP’s. Leg vast welk lokaal subnet zichtbaar wordt voor de andere kant, en noteer het publieke IP-adres van de peer-gateway.
2. Configureer Phase 1 (IKE). Stel het protocol in op IKEv2, kies AES-GCM-256 als versleuteling, een ECDH-groep uit de 19-21 reeks, en de gewenste SA-lifetime. Kies PSK of certificaat als authenticatiemethode.
3. Configureer Phase 2 (IPsec). Bepaal de encryptiedomeinen (bij policy-based) of de VTI-interface met bijbehorende IP-adressen (bij route-based). Stel PFS in en kies een passende SA-lifetime voor deze fase.
4. Kies routing. Bij route-based voeg je statische routes toe naar het externe subnet via de VTI, of je draait BGP over de tunnel voor dynamische routewisseling. Bij policy-based leg je de traffic selectors exact vast.
5. Test de tunnel. Controleer of Phase 1 en Phase 2 SA’s daadwerkelijk zijn opgebouwd, niet alleen dat de interface “up” toont. Ping vanuit een host achter elke gateway naar een host aan de andere kant.
6. Verifieer bereikbaarheid en documenteer. Test meerdere subnets als die aanwezig zijn, leg de configuratie vast in een centraal document of configuratiebeheersysteem, en automatiseer herhaalbare stappen waar mogelijk met infrastructuur-als-code.

Vendors zoals Cisco tonen in hun documentatie concrete commandoreeksen voor precies dit soort IKEv2 route-based configuraties, en Azure biedt een vergelijkbare stapsgewijze tutorial voor wie in de cloud start.

Pro-tip: Zet de tunnel eerst op met een tijdelijke, ruime traffic selector (of een brede VTI-route) voordat je verfijnt naar exact de subnets die je nodig hebt. Zo isoleer je snel of een probleem in de crypto-onderhandeling zit of in de routing, in plaats van beide gelijktijdig te debuggen.

Routing, hoge beschikbaarheid en schaal

Statische routes werken uitstekend bij twee locaties met een voorspelbare topologie. Zodra je drie of meer locaties met elkaar verbindt, of wanneer subnets regelmatig veranderen, wordt BGP de praktischere keuze. BGP over de VPN-tunnel laat beide kanten automatisch nieuwe routes uitwisselen zonder dat iemand handmatig een configuratie moet aanpassen bij elke netwerkwijziging.

Voor hoge beschikbaarheid zet je bij voorkeur twee tunnels op tussen dezelfde locaties, elk via een ander publiek IP-adres. Cloudgateways zoals die van Azure ondersteunen actieve-actieve opstellingen met twee publieke IP’s per gateway-instantie, wat een enkelvoudig faalpunt wegneemt. Oracle Cloud Infrastructure raadt in zijn eigen richtlijnen vergelijkbare dual-tunnel opstellingen aan, samen met routeadvertentie-technieken om asymmetrisch verkeer te beperken.

Bij coexistentie met een dedicated verbinding zoals ExpressRoute of Direct Connect ontwerp je de VPN doorgaans als een failover pad, waarbij de dedicated lijn meestal prioriteit heeft, en de VPN overneemt bij uitval van de dedicated verbinding. Let bij ECMP (equal-cost multi-path) op asymmetrie: als verkeer via de ene tunnel gaat en de reactie via de andere terugkomt, kunnen stateful firewalls het verkeer blokkeren. Prefix-specificiteit en bewust AS-path prepending helpen om één voorkeurspad af te dwingen zonder de tweede tunnel als redundantie te verliezen.

Beveiligings- en hardeningpraktijken

Een tunnel die vandaag veilig is, kan dat over drie jaar niet meer zijn als niemand naar de configuratie omkijkt. Een aantal praktijken houdt de opstelling structureel gezond:

• Cipher suites actueel houden. Controleer periodiek of AES-GCM-256 en de gekozen DH-groep nog als sterk worden beschouwd, en plan een upgradepad voor wanneer dat verandert.
• Sleutels en certificaten roteren. Stel een vaste cyclus in voor PSK-vervanging of certificaatvernieuwing, in plaats van te wachten tot een certificaat verloopt en de tunnel plotseling valt.
• Managementtoegang beperken. Sta configuratiewijzigingen alleen toe vanaf bekende beheeradressen, idealiter via een apart beheernetwerk of jump host.
• Logging en alerting inrichten. Laat het systeem automatisch waarschuwen bij een SA die onverwacht wegvalt, niet pas nadat een gebruiker meldt dat iets niet werkt.
• Segmenteren volgens least privilege. Geef de tunnel alleen toegang tot de subnets die daadwerkelijk nodig zijn, niet het volledige interne netwerk “voor het gemak”.
• Periodiek auditen. Loop minstens jaarlijks de configuratie langs tegen actuele beveiligingsrichtlijnen en compliance-eisen die voor jouw sector gelden.

De veiligheid van een site-to-site VPN zit dus niet alleen in de initiële configuratie. Het zit vooral in de discipline om die configuratie te blijven onderhouden.

Performance tuning en veelvoorkomende valkuilen

Een tunnel die opkomt maar traag aanvoelt, wijst bijna altijd op een MTU- of MSS-probleem. Encryptie voegt overhead toe aan elk pakket: IPsec-headers, ESP-padding en het IP-encapsulatie zelf eten bytes op die anders voor data beschikbaar waren. AWS adviseert in zijn eigen richtlijnen een maximale MTU van 1446 en een MSS van ongeveer 1406 voor klantgateways, precies om ruimte te reserveren voor die overhead.

Zonder die aanpassing ontstaat fragmentatie: pakketten die te groot zijn voor de tunnel worden onderweg opgesplitst, wat vertraging en soms zelfs pakketverlies veroorzaakt. De oplossing is fragmentatie vóór de encryptiestap laten plaatsvinden, niet erna, en op de gateway NAT-bypass regels correct in te stellen zodat verkeer niet dubbel wordt bewerkt.

Herkenbaar probleem: tunnel toont “up”, maar er stroomt geen verkeer. Dit patroon wijst zelden op de crypto-onderhandeling zelf. Controleer in deze volgorde: routing (staat de juiste route naar het externe subnet er wel), NAT-bypass regels (wordt verkeer per ongeluk vertaald voordat het de tunnel bereikt), en MTU-instellingen (worden grote pakketten stil weggegooid). Encryptieoverhead kost ook rekenkracht: op oudere hardware zonder AES-NI-versnelling kan de CPU van de gateway zelf de bottleneck worden bij hogere doorvoersnelheden, iets wat je terugziet in monitoring als de CPU-belasting oploopt terwijl de bandbreedte stagneert.

Troubleshooting checklist: snelle controles en commando’s

Een systematische volgorde voorkomt dat je uren verliest aan het verkeerde probleem. De meeste vendors, van Cisco tot MikroTik, bieden commando’s om Phase 1 en Phase 2 SA’s te inspecteren; de exacte syntax verschilt, maar de logica is universeel.

• Controleer eerst de reachability van het peer-IP. Als je de andere gateway niet eens kunt bereiken, heeft verder debuggen van IKE geen zin.
• Verifieer de Phase 1 (IKE) SA. Staat die er, en met het juiste algoritme en de juiste levensduur? Een ontbrekende SA wijst meestal op een PSK-mismatch of een verkeerd geconfigureerde peer-identiteit.
• Verifieer de Phase 2 (IPsec) SA. Deze bouwt alleen op als Phase 1 al staat. Ontbreekt hij, check dan of de traffic selectors aan beide kanten exact spiegelen.
• Controleer NAT-issues. Een gateway achter NAT die geen NAT-T gebruikt, faalt vaak stil zonder duidelijke foutmelding.
• Bekijk logs en packet captures op de buiteninterface. Foutmeldingen over “no proposal chosen” wijzen op een algoritme-mismatch, terwijl “invalid ID” vaak een verkeerde peer-identiteit aangeeft.

Een bruikbare mentale volgorde: eerst reachability, dan Phase 1, dan Phase 2, dan routing en NAT, en pas als laatste stap een packet capture als niets daarvan het antwoord geeft.

Pro-tip: Houd een vast debug-sjabloon per vendor bij (welk commando toont welke SA, welk logbestand toont welke foutcode) en deel dat binnen je team. Zo hoeft niet elke engineer opnieuw te ontdekken welke commandoreeks bij welk probleem hoort.

Praktijkperspectief van NLXS: wanneer uitbesteden slim is

Niet elk bedrijf heeft de capaciteit om een site-to-site VPN zelf te ontwerpen, laat staan om de tunnel jarenlang te blijven onderhouden. Drie situaties waarin uitbesteden vaker de betere keuze is dan zelf doen: je hebt een strikte SLA nodig die intern niet te garanderen is, je IT-team heeft simpelweg geen tijd naast de dagelijkse operatie, of compliance-eisen vragen om aantoonbare, periodieke controles die je liever niet ad hoc uitvoert.

Bij NLXS beginnen dit soort projecten meestal met een ICT-scan: een inventarisatie van de bestaande netwerkinrichting, risico’s en kosten, voordat er ook maar één tunnel wordt geconfigureerd. Die aanpak voorkomt dat je een VPN bouwt op een fundament dat eigenlijk al problemen had. Sommige klanten vertrouwen op die manier van werken voor hun bredere infrastructuur, met snelle probleemoplossing binnen één dag als vaste norm.

Er zijn partijen die de planning, implementatie, monitoring en doorlopende support van een site-to-site VPN kunnen overnemen, zodat jouw team zich kan richten op de eigen kernactiviteiten in plaats van op tunnelconfiguraties en certificaatrotaties.

Ontwerpkeuzes die vandaag nog stand houden

De aanbeveling in dit artikel, IKEv2 met AES-GCM-256 en een route-based opzet, is geen modegril. Het is de combinatie die vandaag de beste balans biedt tussen beveiliging, prestaties en beheersbaarheid, en die combinatie zal niet snel veranderen zolang de onderliggende standaarden overeind blijven.

Wat wel verschuift, is de context waarin je die tunnel plaatst. SD-WAN en zero trust-architecturen krijgen terecht meer aandacht, maar ze vervangen de klassieke site-to-site VPN zelden volledig. Vaker zie je dat een SD-WAN-oplossing de VPN-tunnels onder de motorkap gebruikt en er alleen een intelligenter beheerlaag boven zet. Zero trust verandert vooral wie toegang krijgt tot wat binnen het netwerk, niet hoe de netwerken onderling versleuteld communiceren.

Mijn advies aan elk team dat een nieuwe tunnel opzet: bouw testen en documentatie vanaf dag één in je routine, niet als nazorg. Een tunnel die je nooit test onder faalcondities, faalt gegarandeerd op het slechtst denkbare moment.

— Ken

Site-to-site VPN uitbesteden aan NLXS

Zelf een site-to-site VPN ontwerpen kost tijd die de meeste IT-teams naast hun dagelijkse werk niet hebben, en een verkeerd ingerichte tunnel merk je vaak pas als er al iets misgaat. Er zijn aanbieders die deze klus in vertrouwde handen nemen met persoonlijke aandacht, directe telefonische bereikbaarheid en problemen die snel worden opgelost, in plaats van langere responstijden die je bij sommige andere partijen tegenkomt.

Elk traject begint met een heldere inventarisatie van je huidige netwerk en risico’s, zodat je vooraf weet waar je aan toe bent, zonder verrassingen in de rekening achteraf. Vanaf daar kan NLXS de volledige implementatie en het doorlopende beheer van je ICT-infrastructuur overnemen, inclusief netwerkverbindingen zoals een site-to-site VPN tussen je vestigingen of richting de cloud.

Wil je weten waar jouw netwerk nu staat en wat een goede VPN-opzet voor jouw situatie kost? Plan een gratis ICT-scan en ontvang binnen korte tijd een concreet advies.

Bronnen

Voor wie de technische details verder wil uitpluizen, zijn dit de bronnen waarop de aanbevelingen in dit artikel steunen:

• Best practices for an AWS Site-to-Site VPN customer gateway device
• Implementing IKEv2 Route-Based Site-to-Site VPN on Cisco Routers Using IPv6 – Cisco

Veelgestelde vragen

Wat is een site-to-site VPN precies?

Een site-to-site VPN is een versleutelde tunnel tussen twee netwerken, opgezet met IPsec en IKE, waarmee locaties of clouds veilig met elkaar communiceren zonder een dedicated lijn te huren.

Is een site-to-site VPN veilig genoeg voor bedrijfsdata?

Met een moderne configuratie, IKEv2, AES-GCM-256 en een sterke ECDH-groep, biedt een site-to-site VPN een sterk beveiligingsniveau, mits sleutels en certificaten periodiek worden geroteerd en de configuratie regelmatig wordt geaudit.

Wat kost een site-to-site VPN implementatie?

De kosten hangen sterk af van het aantal locaties, de gekozen hardware en of je het zelf beheert of uitbesteedt; actuele tarieven voor implementatie en beheer bij NLXS vind je op de website.

Kan ik IPsec gebruiken voor een site-to-site VPN?

Ja, IPsec is samen met IKE de standaardcombinatie voor site-to-site VPN’s en wordt door vrijwel elke vendor en cloudprovider ondersteund, van Cisco en MikroTik tot Azure en AWS.

Wat is het verschil tussen site-to-site en remote access VPN?

Een site-to-site VPN verbindt twee volledige netwerken met elkaar, terwijl een remote access VPN een individuele gebruiker toegang geeft tot één netwerk vanaf een los apparaat.

Aanbevelingen

• VoIP centrale implementeren zonder gedoe
• Zakelijke wifi beveiligen: 8 heldere stappen