Site-to-site VPN met WireGuard: twee locaties veilig verbinden

Een site-to-site VPN verbindt twee complete private netwerken via een versleutelde tunnel. Daardoor kunnen apparaten op locatie A communiceren met apparaten op locatie B alsof er tussen beide netwerken een private netwerkverbinding bestaat.

Dit verschilt duidelijk van een normale VPN voor één laptop.

Bij remote access maakt één gebruiker bijvoorbeeld vanuit huis verbinding met het bedrijfsnetwerk. Bij site-to-site wordt juist de router of gateway van het ene netwerk gekoppeld aan de gateway van het andere netwerk.

Daardoor hoeven medewerkers niet op ieder apparaat afzonderlijk een VPN-client te starten.

Een computer op kantoor A kan bijvoorbeeld rechtstreeks een server op kantoor B bereiken. Ook een NAS, back-upserver, printer of interne applicatie kan via dezelfde route beschikbaar worden gemaakt.

WireGuard is hiervoor goed geschikt. Ubuntu noemt site-to-site expliciet als een normale WireGuard-configuratie voor het verbinden van twee afzonderlijke netwerken via internet.

Wat is een site-to-site VPN?

Stel dat een bedrijf twee vestigingen heeft.

Locatie A gebruikt:

192.168.10.0/24

Locatie B gebruikt:

192.168.20.0/24

Zonder koppeling zijn dit volledig afzonderlijke netwerken.

Een computer op:

192.168.10.25

kan niet zomaar communiceren met een server op:

192.168.20.50

via een private route.

Met een VPN tussen twee locaties plaats je aan beide kanten een WireGuard-gateway.

De verbinding wordt dan:

Netwerk A → WireGuard-gateway A → internet → WireGuard-gateway B → netwerk B

Verkeer tussen beide locaties wordt onderweg door WireGuard versleuteld.

Binnen de lokale netwerken blijft normale IP-routing gebruikt worden.

Waarom een VPN tussen twee netwerken gebruiken?

Een praktische situatie is een bedrijf met een hoofdkantoor en een tweede vestiging.

Op het hoofdkantoor staat bijvoorbeeld een interne server.

De tweede vestiging moet bij die server kunnen, maar je wilt de applicatie niet rechtstreeks voor het gehele internet toegankelijk maken.

Een site-to-siteverbinding lost dat op.

De server kan gewoon zijn private adres houden.

Bijvoorbeeld:

192.168.10.30

Een computer op de andere vestiging gebruikt dat interne IP-adres via de VPN-route.

Voor gebruikers kan dat vrijwel hetzelfde voelen als een server binnen hetzelfde bedrijfsnetwerk.

Toch gaat het verkeer in werkelijkheid versleuteld over internet tussen beide gateways.

Site-to-site VPN versus remote access VPN

Het verschil tussen beide ontwerpen is belangrijk.

Bij remote access heeft iedere externe laptop zijn eigen VPN-configuratie.

De laptop wordt dus zelf WireGuard-peer.

Bij WireGuard site-to-site zijn vooral de netwerkrouters of gateways peers.

Alle apparatuur achter de gateway kan vervolgens via routing van de verbinding gebruikmaken.

Daarom is site-to-site vooral geschikt wanneer volledige locaties permanent met elkaar verbonden moeten zijn.

Voor één medewerker die thuiswerkt is remote access meestal eenvoudiger.

Voor twee kantoren met twintig computers per locatie wil je waarschijnlijk niet veertig afzonderlijke VPN-configuraties beheren als de volledige netwerken gekoppeld kunnen worden.

Hoe ziet een WireGuard site-to-site netwerk eruit?

Voor deze handleiding gebruiken we het volgende voorbeeld.

We gebruiken bewust twee verschillende lokale subnetten.

Dat is essentieel.

Wanneer beide vestigingen bijvoorbeeld 192.168.1.0/24 gebruiken, weet een computer niet automatisch of 192.168.1.50 lokaal staat of via de VPN aan de andere kant bereikbaar moet zijn.

Ubuntu benadrukt bij de officiële site-to-siteconfiguratie eveneens dat de twee lokale netwerken niet mogen overlappen wanneer je gewone routed site-to-siteverbinding gebruikt.

Waarom overlappende subnetten een probleem zijn

Stel dat beide locaties gebruiken:

192.168.1.0/24

Een computer op locatie A probeert:

192.168.1.100

te bereiken.

Volgens zijn lokale netwerkconfiguratie bevindt dat adres zich in hetzelfde LAN.

De computer stuurt het verkeer daardoor niet naar de WireGuard-router.

Hij probeert het apparaat lokaal te vinden.

Daarom kan de VPN niet bepalen dat 192.168.1.100 eigenlijk op locatie B bedoeld wordt.

Er bestaan complexe oplossingen met NAT en netwerkvertaling, maar voor een nieuwe infrastructuur is dat meestal onnodig ingewikkeld.

Het is veel beter vooraf verschillende subnetten te gebruiken.

Bijvoorbeeld:

Locatie A: 192.168.10.0/24

Locatie B: 192.168.20.0/24

Locatie C: 192.168.30.0/24

Daarmee blijft routing logisch en schaalbaar.

Waarom WireGuard een apart tunnelnetwerk krijgt

Naast beide lokale netwerken gebruiken we:

10.200.0.0/30

Dit kleine subnet is alleen bedoeld voor communicatie tussen de twee WireGuard-gateways.

Gateway A krijgt:

10.200.0.1

Gateway B krijgt:

10.200.0.2

De computers achter beide gateways krijgen geen adres uit dit subnet.

Zij behouden gewoon hun normale LAN-adres.

Ubuntu gebruikt in zijn eigen site-to-sitevoorbeeld eveneens een klein afzonderlijk VPN-subnet uitsluitend voor de twee gateways.

Dat maakt de tunnel overzichtelijk.

Waar installeer je WireGuard?

De mooiste situatie ontstaat wanneer WireGuard rechtstreeks op de router of firewall van iedere locatie draait.

Die router is immers al verantwoordelijk voor verkeer tussen het lokale netwerk en andere netwerken.

Wanneer WireGuard daar draait, weet de router direct welke route via de VPN moet lopen.

Niet iedere router ondersteunt WireGuard.

Je kunt daarom ook een aparte Linux-machine gebruiken.

Bijvoorbeeld:

192.168.10.2

op locatie A.

Die machine wordt vervolgens de VPN-gateway.

In dat geval moet de normale netwerkrouter wel weten dat verkeer naar 192.168.20.0/24 via 192.168.10.2 gestuurd moet worden.

Daarvoor gebruik je een statische route.

Site-to-site WireGuard rechtstreeks tussen twee locaties

De eenvoudigste architectuur gebruikt een rechtstreeks bereikbare gateway aan beide kanten.

Bijvoorbeeld:

Locatie A publiek IP: 203.0.113.10

Locatie B publiek IP: 198.51.100.20

Beide firewalls laten de gekozen WireGuard UDP-poort toe.

Daarmee kunnen de gateways rechtstreeks met elkaar communiceren.

Ubuntu beschrijft bij een klassieke permanente site-to-siteopstelling dat beide gateways normaal een stabiel endpoint nodig hebben, bijvoorbeeld een vast IP-adres of geldige hostname.

Een dynamisch publiek IP kan eventueel met Dynamic DNS worden gecombineerd.

CGNAT vraagt echter om een andere architectuur. Daar komen we later op terug.

WireGuard installeren op locatie A

Voor het voorbeeld gebruiken we Ubuntu.

Installeer WireGuard:

sudo apt update
sudo apt install wireguard -y

Maak vervolgens een beveiligde configuratiemap:

sudo mkdir -p /etc/wireguard
sudo chmod 700 /etc/wireguard
cd /etc/wireguard
umask 077

Genereer daarna de sleutel van locatie A:

wg genkey | sudo tee site-a-private.key

Maak de publieke sleutel:

sudo cat site-a-private.key | wg pubkey | sudo tee site-a-public.key

De private key blijft uitsluitend op gateway A.

Locatie B krijgt alleen de publieke sleutel.

WireGuard installeren op locatie B

Voer hetzelfde uit op de tweede gateway:

sudo apt update
sudo apt install wireguard -y

Maak vervolgens de sleutelset:

sudo mkdir -p /etc/wireguard
sudo chmod 700 /etc/wireguard
cd /etc/wireguard
umask 077
wg genkey | sudo tee site-b-private.key
sudo cat site-b-private.key | wg pubkey | sudo tee site-b-public.key

Nu hebben beide gateways hun eigen identiteit.

Dit is een belangrijk principe van WireGuard: iedere peer beschikt over een eigen private/public keypair. AllowedIPs wordt vervolgens gebruikt bij zowel routing als het accepteren van verkeer van peers.

Configuratie van WireGuard op locatie A

Maak:

sudo nano /etc/wireguard/wg0.conf

Een basisconfiguratie wordt:

[Interface]
Address = 10.200.0.1/30
ListenPort = 51820
PrivateKey = PRIVATE_KEY_SITE_A

[Peer]
PublicKey = PUBLIC_KEY_SITE_B
Endpoint = 198.51.100.20:51820
AllowedIPs = 10.200.0.2/32, 192.168.20.0/24
PersistentKeepalive = 25

De belangrijkste regel is:

AllowedIPs = 10.200.0.2/32, 192.168.20.0/24

Daarmee weet locatie A dat het volledige netwerk:

192.168.20.0/24

via WireGuard-peer B bereikbaar is.

WireGuard gebruikt AllowedIPs dus niet alleen als eenvoudige toegangsregel. Het beïnvloedt ook de route van uitgaand verkeer.

Configuratie op locatie B

Aan de andere kant wordt het spiegelbeeld gebruikt:

[Interface]
Address = 10.200.0.2/30
ListenPort = 51820
PrivateKey = PRIVATE_KEY_SITE_B

[Peer]
PublicKey = PUBLIC_KEY_SITE_A
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.200.0.1/32, 192.168.10.0/24
PersistentKeepalive = 25

Locatie B weet nu dat:

192.168.10.0/24

via gateway A bereikbaar is.

Beide WireGuard-gateways hebben daarmee een route naar het externe LAN.

IP forwarding inschakelen

De gateway moet verkeer van het eigen LAN naar WireGuard kunnen doorsturen.

Daarom moet Linux routing toestaan.

Controleer:

sysctl net.ipv4.ip_forward

Wanneer het antwoord:

net.ipv4.ip_forward = 0

is, staat forwarding uit.

Maak vervolgens:

sudo nano /etc/sysctl.d/99-wireguard-site-to-site.conf

Plaats:

net.ipv4.ip_forward=1

Activeer de wijziging:

sudo sysctl --system

Doe dit op beide WireGuard-gateways.

Zonder forwarding kan de gateway zelf via de tunnel communiceren, terwijl computers achter de gateway alsnog geen toegang tot de andere locatie krijgen.

Waarom je bij een echte site-to-site VPN normaal geen NAT gebruikt

Bij een normale site-to-sitearchitectuur wil je dat beide netwerken elkaars echte IP-adressen zien.

Een computer:

192.168.10.25

maakt bijvoorbeeld verbinding met:

192.168.20.50

De server op locatie B hoort dan als bron:

192.168.10.25

te zien.

Daarom maskeer je het verkeer tussen beide locaties normaal gesproken niet.

Ubuntu waarschuwt in de officiële site-to-sitehandleiding expliciet dat verkeer tussen de private netwerken niet gemasquerade of ge-NAT moet worden. Het is gewone routed traffic.

Dat heeft meerdere voordelen.

Logging blijft duidelijk en je kunt firewallregels per werkelijk apparaat of subnet maken.

Wanneer NAT toch wordt gebruikt

Er zijn situaties waarin beheerders toch NAT toepassen.

Bijvoorbeeld wanneer een bestaande router geen statische retourroute ondersteunt.

Ook overlappende subnetten kunnen soms met complexe network address translation worden omgebouwd.

Dat is echter een noodoplossing.

Je verliest daarmee een deel van de transparantie van een echte routed site-to-siteverbinding.

Voor een nieuwe zakelijke infrastructuur zou ik daarom liever de routing correct inrichten.

Wanneer beide locaties verschillende subnetten gebruiken en de routers de juiste routes kennen, is NAT tussen de locaties niet nodig.

WireGuard starten

Op beide gateways:

sudo systemctl enable --now wg-quick@wg0

Controleer:

sudo wg show

Wanneer beide locaties elkaar kunnen bereiken, hoort een recente latest handshake zichtbaar te worden.

Test eerst alleen het tunneladres.

Vanaf locatie A:

ping 10.200.0.2

Vanaf locatie B:

ping 10.200.0.1

Werkt dit niet, dan heeft het nog geen zin om de LAN-routing te onderzoeken.

Eerst moet de WireGuard-tunnel zelf correct functioneren.

Daarna pas het andere netwerk testen

Wanneer het tunneladres bereikbaar is, test je vanuit gateway A bijvoorbeeld:

ping 192.168.20.1

Daarna een echt apparaat:

ping 192.168.20.50

Vervolgens test je vanaf een normale computer op locatie A.

Bijvoorbeeld:

192.168.10.25 → 192.168.20.50

Werkt het vanaf de WireGuard-gateway wel, maar vanaf normale computers niet?

Dan ligt het probleem vrijwel zeker in lokale routing of firewalling.

Die scheiding maakt troubleshooting veel eenvoudiger.

Als WireGuard niet op de hoofdrouter draait

Stel dat locatie A deze structuur heeft:

Router: 192.168.10.1

WireGuard-server: 192.168.10.2

De normale computers gebruiken:

192.168.10.1

als default gateway.

Een computer wil verbinding maken met:

192.168.20.50

Hij stuurt dat pakket naar zijn default gateway 192.168.10.1.

De router moet vervolgens weten dat het netwerk:

192.168.20.0/24

via:

192.168.10.2

bereikbaar is.

Daarvoor stel je op de router een statische route in:

Destination: 192.168.20.0/24
Gateway: 192.168.10.2

Op locatie B doe je hetzelfde in omgekeerde richting.

Waarom retourrouting net zo belangrijk is

Netwerken moeten altijd in twee richtingen kunnen communiceren.

Stel dat een computer van locatie A probleemloos een pakket naar locatie B stuurt.

De server op locatie B ontvangt het.

Maar als de router op locatie B niet weet hoe hij:

192.168.10.0/24

kan bereiken, gaat het antwoord naar de verkeerde gateway.

De gebruiker ziet vervolgens een timeout.

Daarom moet je bij VPN-routing altijd heen én terug controleren.

Een tunnel kan perfect functioneren terwijl applicatieverkeer faalt doordat slechts één kant de juiste route kent.

Firewall tussen beide locaties

Een VPN betekent niet dat je automatisch alle apparatuur van beide locaties volledig moet vertrouwen.

Je kunt verkeer binnen de tunnel nog steeds beperken.

Stel dat locatie B alleen toegang moet krijgen tot een fileserver op locatie A.

Dan hoef je geen toegang te geven tot alle beheersystemen.

De firewall op de gateway kan verkeer per subnet, host, protocol of poort toestaan.

Dat levert een veel betere beveiligingsarchitectuur op dan:

VPN actief = alles overal toegestaan.

Vooral wanneer verschillende vestigingen, externe partners of technische omgevingen gekoppeld worden, is netwerksegmentatie belangrijk.

Site-to-site VPN voor twee kantoren

Dit is waarschijnlijk het meest herkenbare scenario.

Op kantoor A staat bijvoorbeeld de centrale administratie.

Kantoor B gebruikt dezelfde applicatie.

In plaats van deze software publiek via internet beschikbaar te maken, blijft de applicatieserver op een private IP staan.

Bijvoorbeeld:

192.168.10.40

Medewerkers op locatie B openen:

192.168.10.40

via de WireGuard-tunnel.

De applicatie hoeft daardoor geen openbare internetinterface te hebben.

Je kunt hetzelfde toepassen op bestanden, interne dashboards en andere zakelijke systemen.

Centraal bestandsbeheer via WireGuard

Een andere toepassing is een NAS of fileserver.

Stel dat de centrale NAS op locatie A staat:

192.168.10.50

Locatie B krijgt via de site-to-siteverbinding toegang tot dat adres.

Daarmee hoef je de NAS-interface of SMB-service niet rechtstreeks vanaf internet beschikbaar te maken.

De netwerkverbinding wordt afgehandeld via de VPN.

Let wel op snelheid.

Een bestand van 20 GB moet nog steeds via de internetverbinding van beide locaties worden getransporteerd.

De uploadcapaciteit van de locatie waar de NAS staat kan daarom de werkelijke snelheid bepalen.

Internetverbinding bepaalt de VPN-snelheid

Stel dat kantoor A beschikt over:

1 Gbit/s download, 100 Mbit/s upload

en kantoor B over:

1 Gbit/s symmetrisch

Een grote download vanuit kantoor B vanaf een fileserver op kantoor A kan nooit structureel sneller gaan dan ongeveer de beschikbare uploadcapaciteit van kantoor A.

WireGuard kan een snelle VPN-techniek zijn, maar het kan geen netwerkcapaciteit creëren die er niet is.

Ook latency speelt mee.

Twee Nederlandse locaties hebben meestal een kortere netwerkroute dan een verbinding tussen Nederland en Australië.

Voor centrale bestandssystemen moeten beide factoren worden meegenomen.

Site-to-site VPN tussen kantoor en datacenter

De tweede locatie hoeft geen fysiek kantoor te zijn.

Je kunt ook koppelen:

kantoor ↔ datacenter

of:

kantoor ↔ cloud/VPS-netwerk

Stel dat zakelijke applicaties op private servers in een datacenter draaien.

In plaats van ieder intern systeem afzonderlijk publiek te maken, wordt één WireGuard-gateway geplaatst.

Het kantoor krijgt via de tunnel routes naar het private datacenternetwerk.

Daarmee kun je applicaties, databases en beheerinterfaces via private adressen aanbieden.

Dit kan de netwerkarchitectuur een stuk overzichtelijker maken.

Een VPN tussen eigen servers en kantoor

Stel dat in een hostingomgeving verschillende servers draaien:

10.30.0.10 → database
10.30.0.20 → interne applicatie
10.30.0.30 → back-upserver

Het kantoor gebruikt:

192.168.10.0/24

Een bedrijfs-VPN kan beide netwerken koppelen.

Medewerkers bereiken de interne applicatie vervolgens via:

10.30.0.20

De database hoeft niet voor heel internet op poort 3306 beschikbaar te zijn.

Sterker nog, je kunt bepalen dat alleen bepaalde kantoorhosts die database mogen bereiken.

VPN en firewallsegmentatie vullen elkaar zo aan.

Site-to-site VPN met een VPS als hub

Niet iedere situatie maakt een rechtstreekse verbinding tussen twee locaties mogelijk.

Misschien zit één locatie achter CGNAT.

Of beide locaties hebben dynamische verbindingen en je wilt één vast centraal endpoint.

Dan kan een VPS als WireGuard-hub worden gebruikt.

De architectuur wordt:

Locatie A → VPS ← Locatie B

Beide locaties maken zelf een uitgaande tunnel naar de VPS.

De VPS routeert vervolgens verkeer van:

192.168.10.0/24

naar:

192.168.20.0/24

en andersom.

Hiermee krijg je alsnog een volledige VPN tussen twee netwerken, zonder dat beide locaties rechtstreeks een publiek IPv4-adres nodig hebben.

Waarom een VPS-hub goed werkt achter CGNAT

CGNAT verhindert vooral normale nieuwe inkomende IPv4-verbindingen.

Uitgaande verbindingen werken wel.

Daarom kan de WireGuard-router op locatie A zelf een tunnel openen naar een VPS.

Locatie B doet hetzelfde.

De VPS heeft een publiek bereikbaar IP-adres en fungeert als centrale router.

Dit sluit direct aan op onze eerdere handleiding over VPN achter CGNAT.

Het verschil is dat we nu niet één remote laptop naar één thuisnetwerk brengen.

We koppelen twee volledige private subnetten aan elkaar.

Voorbeeld met een centrale WireGuard VPS

Stel dat de VPS intern gebruikt:

10.200.0.1

Locatie A:

10.200.0.2

Locatie B:

10.200.0.3

Het lokale netwerk op A blijft:

192.168.10.0/24

en B:

192.168.20.0/24

Op de VPS wordt peer A gekoppeld aan:

[Peer]
PublicKey = PUBLIC_KEY_A
AllowedIPs = 10.200.0.2/32, 192.168.10.0/24

Peer B:

[Peer]
PublicKey = PUBLIC_KEY_B
AllowedIPs = 10.200.0.3/32, 192.168.20.0/24

De VPS weet daardoor precies via welke peer ieder lokaal netwerk bereikbaar is.

Configuratie van locatie A bij een VPS-hub

Locatie A krijgt bijvoorbeeld:

[Interface]
Address = 10.200.0.2/24
PrivateKey = PRIVATE_KEY_A

[Peer]
PublicKey = PUBLIC_KEY_VPS
Endpoint = vpn.bedrijf.nl:51820
AllowedIPs = 10.200.0.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Locatie A stuurt verkeer naar het netwerk van locatie B dus via de centrale VPS.

Locatie B krijgt dezelfde configuratie in omgekeerde richting.

Deze hub-and-spokeopzet is ook gemakkelijker uit te breiden wanneer later een derde locatie wordt toegevoegd.

Derde vestiging toevoegen

Stel dat er locatie C bijkomt:

192.168.30.0/24

Bij een volledig mesh-netwerk moeten steeds meer locaties rechtstreeks tunnels met elkaar onderhouden.

Met een centrale hub hoeft locatie C alleen met de VPS te verbinden.

De hub kent vervolgens:

192.168.10.0/24 → locatie A

192.168.20.0/24 → locatie B

192.168.30.0/24 → locatie C

Zo ontstaat een schaalbaar hub-and-spoke VPN.

De centrale VPS krijgt daarmee wel een belangrijke rol.

Wanneer deze server uitvalt, kan communicatie tussen verschillende locaties stoppen.

Directe tunnels of centrale VPN-hub?

Een directe tunnel heeft een kortere netwerkroute.

Verkeer tussen kantoor A en B hoeft niet via een derde datacenter.

Dat kan latency en bandbreedte besparen.

Een centrale hub biedt daarentegen eenvoudiger beheer.

Vooral met meerdere locaties of CGNAT wordt dit aantrekkelijk.

Bij drie locaties moet je anders al meerdere onderlinge verbindingen beheren.

Bij tien locaties wordt een volledig mesh-model aanzienlijk complexer.

Daarom zie je bij grotere omgevingen vaak een centrale of gedeeltelijk centrale architectuur.

Welke aanpak beter is hangt af van aantal locaties, beschikbaarheid en netwerkverbindingen.

DNS tussen twee locaties

IP-routing is slechts één onderdeel van een bruikbaar bedrijfsnetwerk.

Gebruikers willen meestal niet onthouden:

192.168.10.45

Ze willen bijvoorbeeld:

fileserver.bedrijf.intern

gebruiken.

Daarom kan interne DNS via de site-to-siteverbinding beschikbaar worden gemaakt.

Stel dat de centrale DNS-server op locatie A staat.

Locatie B kan die resolver via WireGuard bereiken.

Een andere mogelijkheid is op iedere locatie een lokale DNS-server te gebruiken die specifieke interne zones naar de andere locatie doorstuurt.

Dat wordt conditional forwarding genoemd.

Bij grotere bedrijfsnetwerken maakt goede DNS-inrichting het beheer veel eenvoudiger.

Wat gebeurt er wanneer de VPN uitvalt maar DNS blijft verwijzen?

Stel dat:

crm.bedrijf.intern

naar:

192.168.10.40

wijst.

Wanneer de VPN-tunnel uitvalt, blijft DNS dat adres gewoon teruggeven.

De naam werkt dus technisch nog steeds, maar het IP is niet bereikbaar.

Daarom moet bij belangrijke site-to-siteverbindingen niet alleen de tunnel zelf worden gemonitord.

Je wilt eigenlijk weten of een kritieke dienst aan de andere kant functioneel bereikbaar blijft.

Dat is een belangrijk verschil tussen netwerkmonitoring en applicatiemonitoring.

DHCP en site-to-site VPN

Normaal gesproken blijft iedere locatie zijn eigen DHCP-server gebruiken.

Locatie A deelt bijvoorbeeld adressen uit binnen:

192.168.10.0/24

Locatie B gebruikt:

192.168.20.0/24

Je hoeft DHCP-verkeer niet zomaar tussen beide netwerken te verspreiden.

Sterker nog, dat wil je meestal juist voorkomen.

De locaties hebben ieder hun eigen lokale netwerkconfiguratie.

WireGuard routeert alleen verkeer waarvoor een route naar het andere subnet bestaat.

Dat maakt de infrastructuur stabieler wanneer de internetverbinding tussen locaties tijdelijk wegvalt.

Wat gebeurt er als de site-to-site VPN wegvalt?

Lokale apparatuur op iedere vestiging blijft normaal gewoon werken.

Een computer op locatie A kan nog steeds andere systemen binnen:

192.168.10.0/24

bereiken.

Alleen diensten die zich aan de andere kant van de VPN bevinden worden onbereikbaar.

Daarom moet je bij het centraliseren van bedrijfsdiensten nadenken over afhankelijkheid.

Wanneer internet op kantoor B wegvalt en alle bestanden uitsluitend op kantoor A staan, kunnen medewerkers op B mogelijk niet verder werken.

Een site-to-siteverbinding is dus niet alleen een netwerkproject.

Het heeft ook gevolgen voor bedrijfscontinuïteit.

Twee internetverbindingen gebruiken voor VPN-failover

Voor belangrijke locaties kun je twee internetverbindingen gebruiken.

Bijvoorbeeld:

glasvezel primair

en:

5G secundair

Wanneer de primaire verbinding uitvalt, kan een router de WireGuard-route opnieuw via de tweede verbinding opbouwen.

Het ontwerp wordt dan complexer.

De remote peer moet namelijk weten welk endpoint bereikbaar is of beide endpoints moeten vooraf beschikbaar zijn.

Met een centrale VPN-hub is dit soms eenvoudiger, omdat beide WAN-verbindingen zelf uitgaand verbinding kunnen maken met hetzelfde centrale endpoint.

Voor zeer kritieke verbindingen kan een tweede onafhankelijke WireGuard-hub eveneens interessant zijn.

Site-to-site VPN failover met twee VPS’en

Een centrale VPS creëert zelf een nieuw single point of failure.

Daarom kun je twee VPN-hubs gebruiken.

Bijvoorbeeld:

VPN-hub 1 → Amsterdam

VPN-hub 2 → Frankfurt

Beide locaties hebben een tunnel naar beide servers.

De primaire route gebruikt normaal hub 1.

Wanneer die route faalt, kan verkeer via hub 2 worden gestuurd.

Hiervoor heb je aanvullende routinglogica en monitoring nodig.

Voor een klein bedrijf is dat mogelijk overdreven.

Voor infrastructuur die altijd bereikbaar moet blijven, kan het wel zinvol zijn.

Firewallregels per vestiging

Stel dat locatie A de hoofdvestiging is en locatie B een kleine nevenvestiging.

Locatie B hoeft misschien alleen toegang tot:

192.168.10.50 → fileserver

en:

192.168.10.60 → administratie.

Er is geen reden om locatie B automatisch toegang te geven tot iedere beheerinterface op locatie A.

De VPN-gateway kan dit beperken.

Daarmee wordt de site-to-siteverbinding niet één groot plat netwerk.

Je houdt aparte subnetten en definieert expliciet welke communicatie toegestaan is.

Dat is zowel veiliger als makkelijker te beheren.

Site-to-site VPN en netwerksegmentatie

Je kunt dit concept nog verder uitbreiden.

Stel dat locatie A verschillende VLAN’s gebruikt:

192.168.10.0/24 → medewerkers

192.168.11.0/24 → servers

192.168.12.0/24 → gasten

Locatie B hoeft waarschijnlijk geen route naar het gastennetwerk.

In AllowedIPs en de firewalls kun je alleen de relevante netwerken opnemen.

Bijvoorbeeld:

192.168.10.0/24
192.168.11.0/24

Het gastennetwerk blijft volledig lokaal.

Zo combineer je WireGuard met bestaande netwerksegmentatie.

AllowedIPs goed begrijpen

Dit onderdeel veroorzaakt veel WireGuard-fouten.

Op locatie A heb je bijvoorbeeld:

AllowedIPs = 192.168.20.0/24

Dit betekent dat verkeer naar locatie B via die peer wordt gestuurd.

Aan de andere kant moet B juist hebben:

AllowedIPs = 192.168.10.0/24

Wanneer je aan beide kanten per ongeluk het eigen lokale netwerk invult, ontstaan verkeerde routes.

WireGuard gebruikt AllowedIPs daarnaast om te controleren welke bronadressen een peer mag gebruiken bij binnenkomend verkeer.

Daarom moet dit veld zorgvuldig met de netwerkarchitectuur overeenkomen.

Wat als de WireGuard handshake werkt maar LAN-verkeer niet?

Dit is een zeer nuttige diagnose.

Wanneer:

sudo wg show

een recente handshake laat zien en beide tunnel-IP’s elkaar kunnen pingen, werkt WireGuard zelf.

Dan moet je niet willekeurig nieuwe keys maken.

Controleer vervolgens IP forwarding.

Daarna de routes op beide gateways.

Vervolgens de retourroute op de normale LAN-router.

Tot slot de firewall.

Door in die volgorde te testen voorkom je dat verschillende problemen door elkaar worden gehaald.

Handshake werkt helemaal niet

Dan zit het probleem eerder.

Controleer of beide endpoints naar het juiste publieke IP of hostname verwijzen.

Controleer de UDP-poort.

Controleer de providerfirewall en lokale firewall.

Bekijk daarna de publieke keys.

Ook DNS kan een rol spelen wanneer je een hostname als endpoint gebruikt.

Pas wanneer er een geldige handshake ontstaat, heeft het zin LAN-routing verder te onderzoeken.

WireGuard site-to-site en MTU

Bij sommige netwerkverbindingen kan een verkeerde Maximum Transmission Unit problemen veroorzaken.

Kleine pakketten lijken dan te werken, terwijl grotere verbindingen vreemd vastlopen.

Dit kan bijvoorbeeld zichtbaar worden bij bestandsoverdrachten of bepaalde websites.

Verander MTU echter niet zomaar op basis van één willekeurige tutorial.

Controleer eerst of packet size daadwerkelijk het probleem is.

Netwerken via PPPoE, bepaalde mobiele verbindingen of extra tunneltechnieken kunnen een kleinere effectieve MTU hebben.

Pas de waarde alleen aan wanneer metingen daar aanleiding toe geven.

Site-to-site VPN en IPv6

WireGuard kan ook IPv6 tussen locaties routeren.

Daarmee kun je naast IPv4-private netwerken eveneens IPv6-prefixen bereikbaar maken.

Het principe blijft vergelijkbaar.

Beide locaties hebben verschillende IPv6-netwerken en AllowedIPs bevat de prefix van de andere locatie.

IPv6 maakt NAT tussen de locaties meestal helemaal niet nodig.

Firewallbeleid blijft echter essentieel.

Een publiek routable IPv6-adres betekent niet dat iedere dienst onbeperkt vanaf internet bereikbaar moet zijn.

Voor een eerste implementatie is IPv4 vaak eenvoudiger. Daarna kan dual stack bewust worden toegevoegd.

Site-to-site VPN voor back-ups

Een praktische toepassing is een externe back-upserver.

Stel dat de productieserver op locatie A staat.

Locatie B heeft een NAS waarop iedere nacht een extra back-up wordt opgeslagen.

Via een site-to-siteverbinding kan de productieserver de NAS bereiken via een private route.

De NAS hoeft geen publieke bestandspoorten te hebben.

Dat maakt de netwerkarchitectuur veiliger.

Let wel op ransomware en accountrechten.

Een VPN-verbinding alleen zorgt er niet voor dat de back-up onveranderbaar is.

De opslag zelf moet eveneens goed worden beschermd.

Back-ups kunnen veel VPN-bandbreedte gebruiken

Een nachtelijke back-up van 500 GB vraagt aanzienlijk meer van een site-to-siteverbinding dan het openen van een interne webapplicatie.

Daarom moet je rekening houden met de uploadverbinding.

Stel dat een locatie slechts 50 Mbit/s upload heeft.

Dan duurt een zeer grote eerste volledige back-up lang.

Incrementele back-ups verminderen dit probleem omdat daarna alleen wijzigingen hoeven te worden verzonden.

Je kunt grote back-uptaken bovendien buiten kantooruren plannen.

Zo concurreren ze minder met normaal bedrijfsverkeer.

QoS en bedrijfskritisch verkeer

Op drukke verbindingen kan Quality of Service relevant worden.

Stel dat een back-up alle beschikbare uploadcapaciteit gebruikt.

Een medewerker probeert tegelijkertijd via de site-to-siteverbinding een interactieve bedrijfsapplicatie te gebruiken.

De ervaring kan dan traag worden.

Met traffic shaping of QoS kun je bepaalde netwerkstromen prioriteit geven.

WireGuard lost dit zelf niet op.

WireGuard verzorgt vooral de versleutelde tunnel.

Netwerkprioritering blijft een taak voor routers en firewalls.

Site-to-site VPN versus cloudapplicaties

Een site-to-siteverbinding is vooral nuttig voor private netwerkdiensten.

Wanneer alle bedrijfssoftware volledig als publieke SaaS wordt gebruikt, heb je mogelijk minder noodzaak om kantoren onderling te verbinden.

Maar zelfs dan kunnen er lokale apparaten bestaan.

Denk aan een NAS, telefooncentrale, printerserver of intern beheersysteem.

Daarom moet je eerst inventariseren welke systemen daadwerkelijk tussen locaties bereikbaar moeten zijn.

Bouw geen complexe VPN omdat “bedrijven nu eenmaal een VPN horen te hebben”.

De architectuur moet een concreet netwerkprobleem oplossen.

WireGuard site-to-site versus IPsec

IPsec wordt al jarenlang veel gebruikt voor verbindingen tussen firewalls en bedrijfslocaties.

Veel professionele routers ondersteunen het standaard.

WireGuard heeft een andere aanpak en een relatief compacte configuratie.

Voor Linux-gebaseerde infrastructuur kan WireGuard daardoor aantrekkelijk zijn.

IPsec kan echter logischer zijn wanneer bestaande firewalls hier al volledig voor zijn ingericht.

De keuze hangt dus niet alleen van het protocol af.

Ook hardware, beheerervaring en compatibiliteit met bestaande infrastructuur tellen mee.

Het belangrijkste is dat de oplossing betrouwbaar beheerd kan worden.

Site-to-site VPN en Zero Trust

Een traditionele site-to-siteverbinding geeft twee netwerken vaak relatief brede toegang tot elkaar.

Moderne beveiligingsmodellen proberen toegang juist specifieker te maken.

Die twee ideeën hoeven elkaar niet tegen te spreken.

Je kunt WireGuard gebruiken voor veilige transportverbindingen en vervolgens met firewalls bepalen welke systemen elkaar mogen bereiken.

Een computer op locatie B hoeft bijvoorbeeld niet automatisch SSH-toegang tot iedere server op locatie A te krijgen.

De tunnel beschermt het transport.

Firewallregels bepalen vervolgens de daadwerkelijke netwerktoegang.

Monitoring van een site-to-site VPN

Een permanente bedrijfsverbinding hoort gemonitord te worden.

Alleen controleren of WireGuard als proces actief is, is onvoldoende.

De interface kan bestaan terwijl de remote peer al een uur geen handshake meer heeft uitgevoerd.

Daarom kun je controleren op:

latest handshake

maar ook op werkelijke bereikbaarheid van systemen aan de andere kant.

Een goede monitoringtest kan bijvoorbeeld periodiek een intern gatewayadres of applicatie controleren.

Zo ontdek je niet alleen dat WireGuard draait, maar ook dat de VPN tussen twee locaties functioneel bruikbaar is.

Logging zonder onnodig netwerkverkeer vast te leggen

WireGuard zelf houdt de opzet relatief eenvoudig.

Je hoeft niet automatisch al het verkeer van medewerkers te loggen.

Voor technisch beheer zijn vooral netwerkstatus en verbindingsproblemen belangrijk.

Denk aan laatste handshake, interface-status en hoeveelheid verkeer.

Aanvullende firewalllogging kan nuttig zijn bij beveiligingsproblemen.

Verzamel echter alleen informatie waarvoor een duidelijk doel bestaat.

Een interne VPN is geen reden om al het gebruikersverkeer onbeperkt te bewaren.

Back-up van de WireGuard-configuratie

De configuratie van beide gateways is klein, maar belangrijk.

Bewaar:

/etc/wireguard/

op een veilige plaats.

Daar kunnen private keys in staan.

Een back-up van deze map moet daarom als gevoelig worden behandeld.

Bij een volledig serverherstel kun je hiermee dezelfde VPN-identiteit opnieuw opbouwen.

Je kunt ook nieuwe keys genereren, maar dan moeten de publieke sleutels op alle andere peers worden vervangen.

Bij meerdere locaties kan goed configuratiebeheer daarom veel tijd besparen.

Documenteer alle subnetten

Bij één tunnel kun je veel informatie nog onthouden.

Bij vijf locaties niet.

Maak daarom een duidelijk IP-plan.

Bijvoorbeeld:

Hiermee voorkom je dat een nieuwe locatie per ongeluk hetzelfde subnet krijgt als een bestaande vestiging.

Dat lijkt een klein administratief detail, maar het voorkomt later complexe routingproblemen.

Wat gebeurt er bij een fusie van twee bestaande netwerken?

Dit is een situatie waarin overlapping juist vaak voorkomt.

Bedrijf A gebruikt:

192.168.1.0/24

Bedrijf B toevallig ook.

Je kunt die netwerken niet zonder meer transparant aan elkaar routeren.

Een structurele oplossing is één netwerk hernummeren.

Dat kost werk, maar levert daarna een veel nettere infrastructuur op.

Voor tijdelijke koppelingen kun je NAT-constructies gebruiken waarbij netwerken virtueel naar andere adressen worden vertaald.

Dat maakt beheer echter complexer.

Wanneer de verbinding permanent wordt, verdient hernummering meestal de voorkeur.

Site-to-site VPN voor internationale locaties

WireGuard werkt ook tussen landen.

De fysieke afstand blijft echter relevant.

Een tunnel Nederland-Duitsland heeft meestal een veel lagere latency dan Nederland-Singapore.

Wanneer applicaties veel kleine opeenvolgende netwerkverzoeken uitvoeren, kan hoge latency merkbaar zijn.

Een centraal bestandssysteem over duizenden kilometers is daardoor niet altijd prettig, zelfs wanneer voldoende bandbreedte beschikbaar is.

Soms is replicatie van gegevens verstandiger dan ieder bestand voortdurend over de lange VPN-route te openen.

Netwerkarchitectuur en applicatiearchitectuur horen daarom samen bekeken te worden.

Beveiliging van de WireGuard gateways

Een VPN-gateway is belangrijk voor de volledige netwerkverbinding.

Houd daarom het onderliggende besturingssysteem actueel.

Beperk beheerinterfaces.

Gebruik SSH-keys.

Beveilig private WireGuard-keys.

Controleer de firewall.

Wanneer de gateway gecompromitteerd raakt, kan een aanvaller mogelijk toegang krijgen tot routes naar andere bedrijfsnetwerken.

De VPN zelf kan cryptografisch sterk zijn, maar een slecht onderhouden server blijft een risico.

Beveilig dus niet alleen de tunnel. Beveilig ook de systemen aan beide uiteinden.

Site-to-site VPN met Plesk of DirectAdmin servers

Een remote server hoeft niet per se onderdeel van een traditioneel kantoor-LAN te zijn.

Je kunt bijvoorbeeld een netwerk met DirectAdmin- of Plesk-servers via WireGuard aan een beheeromgeving koppelen.

Hierdoor kunnen beheerinterfaces via private adressen bereikbaar worden.

Een organisatie kan bijvoorbeeld SSH, databasebeheer en interne monitoring alleen via de VPN toestaan.

Publieke websites blijven gewoon via poort 80 en 443 bereikbaar.

Beheer krijgt een aparte private route.

Dit kan het publieke aanvalsoppervlak van serverbeheer sterk verkleinen.

Site-to-site VPN of VPN met vast IP?

Deze oplossingen lijken op elkaar, maar hebben een ander doel.

Een VPN met vast IP-adres zorgt ervoor dat gebruikers via één vertrouwd publiek IP naar buiten gaan.

Een site-to-siteverbinding koppelt juist complete private subnetten.

Voor serverwhitelisting kan één centrale VPN met vast IP voldoende zijn.

Wil je dat een volledige kantooromgeving private servers in een datacenter kan benaderen, dan past site-to-site beter.

Beide technieken kunnen overigens gecombineerd worden.

Dezelfde VPN-infrastructuur kan zowel private routes als een gecontroleerde internetuitgang aanbieden.

Site-to-site VPN laten opzetten door Sanum

Sanum kan een site-to-site VPN met WireGuard inrichten voor bedrijven die vestigingen, servers of private netwerken veilig met elkaar willen verbinden.

Daarbij begint de configuratie niet met het installeren van WireGuard, maar met het netwerkontwerp.

De bestaande subnetten moeten worden gecontroleerd. Vervolgens moet duidelijk zijn welke locaties rechtstreeks met elkaar kunnen verbinden en welke verbindingen mogelijk achter CGNAT staan.

Daarna kunnen de WireGuard-gateways, routes en firewallregels worden ingericht.

Ook een centrale VPS kan als VPN-hub worden gebruikt wanneer meerdere locaties moeten worden gekoppeld of geen van de vestigingen een bruikbaar publiek IPv4-adres heeft.

Voor zakelijke omgevingen kunnen daarnaast monitoring, interne DNS, back-ups en een secundaire VPN-route worden meegenomen.

Wil je twee kantoren, servers of bedrijfsnetwerken via een beveiligde WireGuard-tunnel verbinden? Sanum kan het netwerkplan, de VPN-gateways, routing en firewallconfiguratie volledig inrichten.

Veelgestelde vragen over site-to-site VPN

Wat is een site-to-site VPN?

Een site-to-site VPN verbindt twee of meer complete netwerken via een versleutelde tunnel. Apparaten achter de gateways kunnen daardoor systemen aan de andere locatie via private netwerkadressen bereiken.

Wat is het verschil met een normale VPN voor thuiswerken?

Bij een thuiswerk-VPN maakt meestal één laptop verbinding met een bedrijfsnetwerk. Bij site-to-site worden de gateways van volledige netwerken met elkaar gekoppeld.

Kan WireGuard een site-to-site VPN maken?

Ja. WireGuard ondersteunt dit scenario. Ubuntu documenteert site-to-site expliciet als een normale toepassing voor het koppelen van twee verschillende netwerken.

Moeten beide locaties een vast IP-adres hebben?

Niet altijd. Een vaste publieke hostname of Dynamic DNS kan bij dynamische publieke adressen helpen. Bij CGNAT kan een centrale VPS als publiek WireGuard-endpoint worden gebruikt.

Kunnen beide locaties achter CGNAT zitten?

Ja. Beide WireGuard-gateways kunnen zelf een uitgaande tunnel naar dezelfde publiek bereikbare VPS maken. De VPS routeert vervolgens verkeer tussen beide locaties.

Mogen beide locaties hetzelfde subnet gebruiken?

Voor een normale routed site-to-siteverbinding is dat een probleem. Gebruik bij voorkeur verschillende subnetten. Ubuntu noemt niet-overlappende netwerken eveneens als uitgangspunt voor zijn site-to-siteopzet.

Moet ik NAT gebruiken tussen twee locaties?

Bij een echte routed site-to-siteverbinding normaal niet. De oorspronkelijke private IP-adressen blijven zichtbaar. Ubuntu adviseert eveneens geen masquerading toe te passen op verkeer tussen de twee sites.

Waarom heb ik IP forwarding nodig?

De WireGuard-gateway moet pakketten tussen het lokale LAN en de VPN-interface kunnen routeren. Daarvoor moet forwarding op het gateway-systeem zijn toegestaan.

Wat doet AllowedIPs?

WireGuard gebruikt AllowedIPs voor routing van uitgaand verkeer en controle van adressen bij inkomend verkeer. Daarom moet het remote subnet bij de juiste peer worden ingesteld.

Kan ik drie of meer kantoren met WireGuard koppelen?

Ja. Je kunt directe tunnels tussen locaties bouwen of een centrale hub gebruiken. Bij meerdere vestigingen wordt een hub-and-spokeopzet vaak overzichtelijker.

Kan een VPS de centrale VPN-router zijn?

Ja. Dat is vooral praktisch wanneer locaties achter CGNAT zitten of wanneer je één centraal publiek endpoint wilt gebruiken.

Hoe snel is een site-to-site VPN?

De snelheid wordt onder andere bepaald door internetverbindingen, uploadcapaciteit, latency, server- of routerhardware en netwerkroute. De langzaamste schakel beperkt uiteindelijk de verbinding.

Kan ik een NAS via site-to-site VPN gebruiken?

Ja. Een NAS op de ene locatie kan via zijn private IP-adres vanaf de andere vestiging bereikbaar worden gemaakt zonder de NAS-service rechtstreeks publiek te publiceren.

Kan ik databases via de VPN bereikbaar maken?

Ja. Dit is juist een nuttige toepassing. Een database kan uitsluitend private netwerktoegang accepteren terwijl geautoriseerde systemen op de andere locatie hem via WireGuard bereiken.

Kan ik verkeer tussen locaties beperken?

Ja. Gebruik firewallregels om alleen noodzakelijke hosts en diensten toe te staan. Een actieve VPN hoeft niet te betekenen dat beide netwerken onbeperkt toegang tot elkaar krijgen.

Wat gebeurt er wanneer de internetverbinding uitvalt?

De lokale netwerken blijven normaal werken, maar diensten aan de andere kant van de tunnel worden tijdelijk onbereikbaar.

Kan ik een tweede internetverbinding als failover gebruiken?

Ja. Met geschikte routering kan WireGuard bij uitval via een tweede WAN-verbinding opnieuw worden opgebouwd. Voor kritieke infrastructuur kun je ook een tweede centrale VPN-hub gebruiken.

Kan WireGuard naast Plesk of DirectAdmin worden gebruikt?

Ja. Je kunt bijvoorbeeld serverbeheer en databases via een private WireGuard-route beschikbaar maken, terwijl de publieke websites gewoon via internet bereikbaar blijven.

Heb ik op iedere computer WireGuard nodig?

Niet wanneer de WireGuard-gateway de routing voor het hele netwerk verzorgt. De individuele computers gebruiken dan hun normale lokale netwerkconfiguratie.

Kan interne DNS over de VPN werken?

Ja. Een DNS-server op de ene locatie kan via de tunnel gebruikt worden of beide locaties kunnen conditional forwarding toepassen voor interne domeinnamen.

Is een site-to-site VPN hetzelfde als failover?

Nee. De VPN verzorgt netwerkconnectiviteit. Failover gaat over het automatisch gebruiken van een alternatieve route of server wanneer de primaire omgeving uitvalt. Beide technieken kunnen wel gecombineerd worden.