Een VPN achter CGNAT opzetten vraagt een andere aanpak dan een normale VPN-server thuis. Het belangrijkste probleem is namelijk niet WireGuard, je router of de gebruikte UDP-poort. Het probleem zit een niveau hoger in het netwerk van je internetprovider.
Bij een normale thuisverbinding krijgt je router een publiek IP-adres. Je kunt vervolgens een poort vanaf dat adres doorsturen naar een apparaat binnen je eigen netwerk.
Bij Carrier-Grade NAT, meestal afgekort tot CGNAT, deelt de internetprovider één of meerdere publieke IPv4-adressen met meerdere klanten.
Je router bevindt zich daardoor zelf al achter een NAT-laag van de provider.
Het gevolg is belangrijk: een normale port forwarding in je eigen router is dan niet genoeg om een VPN-server thuis vanaf internet bereikbaar te maken.
Gelukkig betekent dat niet dat je geen eigen VPN kunt gebruiken.
Je moet alleen de richting van de verbinding anders ontwerpen.
Wat is CGNAT precies?
IPv4-adressen zijn beperkt beschikbaar. Internetproviders kunnen daarom Carrier-Grade NAT gebruiken om meerdere aansluitingen achter gedeelde publieke IPv4-adressen te plaatsen.
Je eigen router krijgt dan niet rechtstreeks het publieke internetadres waarmee websites jouw verbinding zien.
Er zit nog een routerings- en vertaallaag bij de provider tussen.
Voor gedeelde adresruimte is in RFC 6598 het bereik:
100.64.0.0/10
gereserveerd.
Dat loopt van:
100.64.0.0
tot:
100.127.255.255
Dit adresbereik is bedoeld voor gedeelde adresruimte binnen providernetwerken en hoort niet als normaal publiek IPv4 over het internet te worden gerouteerd.
Een provider kan voor bepaalde interne netwerkconstructies overigens ook andere niet-publieke adressen gebruiken. Kijk daarom niet alleen naar één nummerreeks wanneer je probeert vast te stellen of CGNAT actief is.
Waarom gebruiken providers CGNAT?
De belangrijkste achtergrond is het tekort aan beschikbare IPv4-adressen.
Een traditionele internetverbinding gebruikt één uniek publiek IPv4-adres per klant.
Bij honderdduizenden aansluitingen zijn dus honderdduizenden IPv4-adressen nodig.
Met CGNAT kunnen meerdere klanten via dezelfde publieke IPv4-infrastructuur het internet op.
Voor normaal internetgebruik merk je daar vaak nauwelijks iets van.
Je browser opent websites, streaming werkt en je telefoon kan verbinding maken met externe diensten.
Het probleem verschijnt vooral wanneer iemand vanaf internet juist een nieuwe verbinding naar jouw thuisnetwerk moet beginnen.
Een eigen VPN-server is precies zo’n toepassing.
Waarom werkt port forwarding niet achter CGNAT?
Stel dat je thuis een WireGuard-server hebt op:
192.168.1.50
Je router krijgt normaal een publiek adres zoals:
203.0.113.40
Je maakt dan een port forward:
203.0.113.40:51820 UDP → 192.168.1.50:51820
Een laptop onderweg kan het publieke adres bereiken. Je eigen router ontvangt het pakket en stuurt het door naar de WireGuard-server.
Achter CGNAT ziet de situatie er anders uit.
Je eigen router krijgt bijvoorbeeld:
100.72.18.25
Dat is niet het adres waarmee je uiteindelijk het openbare internet op gaat.
Verderop in het netwerk van de provider vindt nóg een NAT-vertaling plaats naar een publiek adres.
Je kunt je eigen router wel vertellen om UDP 51820 door te sturen, maar je hebt geen controle over de NAT-router van de internetprovider.
Een inkomend pakket bereikt daardoor je eigen router meestal helemaal niet.
Daarom kun je het probleem niet oplossen door steeds andere port-forwardingregels te proberen.
Hoe herken je of je achter CGNAT zit?
Begin met het WAN-adres dat je router ontvangt.
Open de internet- of WAN-status van je router en zoek het IPv4-adres van de verbinding.
Vergelijk dit vervolgens met het publieke IPv4-adres dat een externe IP-controleservice laat zien.
Stel dat je router zegt:
100.76.34.19
terwijl internetdiensten jouw verbinding zien als:
198.51.100.84
Dan vindt er buiten je eigen router nog een adresvertaling plaats.
Wanneer het WAN-adres binnen 100.64.0.0/10 ligt, is dat bovendien een sterke aanwijzing voor het gedeelde adresbereik dat speciaal voor dit soort providernetwerken is gereserveerd.
Ook een WAN-adres uit een gewone private adresreeks terwijl een andere publieke IPv4-waarde zichtbaar is, betekent dat er nog NAT vóór jouw router aanwezig is.
Waarom werkt uitgaand internet achter CGNAT wel?
Dit lijkt in eerste instantie tegenstrijdig.
Als externe apparaten jouw thuisserver niet kunnen bereiken, waarom kun jij vanaf thuis dan wel gewoon iedere website openen?
Dat komt doordat de verbinding vanuit jouw netwerk wordt gestart.
Je computer stuurt eerst een pakket naar buiten.
De verschillende NAT-systemen onthouden vervolgens tijdelijk welke interne verbinding bij welke externe verbinding hoort.
Antwoorden kunnen daardoor langs dezelfde route terugkomen.
Een compleet nieuwe inkomende verbinding heeft die bestaande status niet.
De provider weet dan niet automatisch naar welke klant achter het gedeelde publieke IP-adres het pakket moet worden gestuurd.
Dat verschil tussen uitgaand starten en inkomend bereikbaar zijn is de sleutel tot vrijwel iedere CGNAT-oplossing.
VPN achter CGNAT oplossen door de verbinding om te draaien
Wanneer je thuisserver niet rechtstreeks bereikbaar kan zijn, kun je ervoor zorgen dat de thuisserver zelf een verbinding naar buiten opent.
Daarvoor gebruik je bijvoorbeeld een kleine VPS met een echt publiek IPv4-adres.
De thuisserver maakt vanuit het CGNAT-netwerk een WireGuard-tunnel naar die VPS.
Omdat deze verbinding vanuit huis wordt gestart, kan CGNAT er normaal mee omgaan.
De architectuur wordt:
thuisnetwerk → uitgaande WireGuard-tunnel → VPS met publiek IP
Wanneer jij later vanaf je laptop verbinding maakt, verbind je niet rechtstreeks met je huis.
Je verbindt met de publiek bereikbare VPS.
Vanaf de VPS bestaat al een tunnel terug naar het thuisnetwerk.
Zo wordt de VPS als het ware de publiek bereikbare voordeur van een netwerk dat zelf geen openbare IPv4-ingang heeft.
Waarom een VPS deze constructie oplost
Een normale VPS in een datacenter heeft meestal een publiek IP-adres dat vanaf internet bereikbaar is.
Daar kun je bijvoorbeeld WireGuard laten luisteren op:
51820/UDP
Je telefoon of laptop kan dat adres gewoon bereiken.
De thuisserver hoeft ondertussen geen enkele publieke inkomende poort te hebben.
Die server onderhoudt zelf een uitgaande WireGuard-verbinding met de VPS.
Hierdoor kunnen drie netwerken met elkaar worden verbonden:
laptop onderweg ↔ VPS ↔ thuisnetwerk
De VPS functioneert daarmee als router tussen de externe WireGuard-client en de WireGuard-peer thuis.
Je omzeilt CGNAT dus niet door de NAT-laag van de provider te kraken of te verwijderen.
Je bouwt simpelweg een netwerkroute waarvoor geen inkomende verbinding naar de thuisrouter nodig is.
Voorbeeld van de netwerkopbouw
Stel dat thuis het volgende netwerk wordt gebruikt:
192.168.1.0/24
De thuisserver heeft:
192.168.1.10
Voor de WireGuard-tunnel gebruiken we:
10.50.0.0/24
De VPS krijgt binnen WireGuard:
10.50.0.1
De thuisserver krijgt:
10.50.0.2
Een laptop onderweg krijgt:
10.50.0.3
De structuur wordt dan:
| Onderdeel | Adres |
|---|---|
| VPS publiek | bijvoorbeeld 203.0.113.50 |
| VPS WireGuard | 10.50.0.1 |
| Thuisserver WireGuard | 10.50.0.2 |
| Laptop WireGuard | 10.50.0.3 |
| Thuisnetwerk | 192.168.1.0/24 |
| Thuisserver LAN | 192.168.1.10 |
Je laptop maakt verbinding met 203.0.113.50.
Vanaf daar kan de VPS verkeer voor 192.168.1.0/24 door de tunnel naar 10.50.0.2 sturen.
Zo kun je uiteindelijk bijvoorbeeld een NAS bereiken op:
192.168.1.20
zonder dat de NAS zelf publiek bereikbaar is.
WireGuard installeren op de VPS
We gaan uit van Ubuntu 24.04.
Installeer eerst WireGuard:
sudo apt update
sudo apt install wireguard -y
Controleer daarna welke publieke netwerkinterface de VPS gebruikt:
ip route
Je ziet bijvoorbeeld:
default via 203.0.113.1 dev ens3
In dat voorbeeld is ens3 de publieke netwerkinterface.
Dat wordt later belangrijk wanneer je verkeer wilt routeren of NAT wilt toepassen.
Sleutels voor de VPS maken
WireGuard gebruikt per peer een publieke en private sleutel.
Maak de map goed afgeschermd:
sudo mkdir -p /etc/wireguard
sudo chmod 700 /etc/wireguard
cd /etc/wireguard
umask 077
Genereer daarna de serverkey:
wg genkey | sudo tee vps_private.key
Maak de bijbehorende publieke sleutel:
sudo cat vps_private.key | wg pubkey | sudo tee vps_public.key
De private sleutel blijft op de VPS.
Alleen de publieke sleutel geef je aan andere WireGuard-peers.
WireGuard configureren op de VPS
Maak:
sudo nano /etc/wireguard/wg0.conf
De basis kan bijvoorbeeld zijn:
[Interface]
Address = 10.50.0.1/24
ListenPort = 51820
PrivateKey = PRIVATE_KEY_VPS
Daarna voegen we de thuisserver toe:
[Peer]
PublicKey = PUBLIC_KEY_THUISSERVER
AllowedIPs = 10.50.0.2/32, 192.168.1.0/24
Deze AllowedIPs zijn belangrijk.
Hiermee weet de VPS dat verkeer voor:
10.50.0.2
en:
192.168.1.0/24
via de thuispeer moet worden gestuurd.
De VPS hoeft dus geen rechtstreekse route naar het thuisnetwerk te hebben.
WireGuard levert die route via de tunnel.
WireGuard op de thuisserver installeren
Ook de thuisserver moet WireGuard draaien.
Op Ubuntu of Debian kan dat bijvoorbeeld met:
sudo apt update
sudo apt install wireguard -y
Genereer vervolgens op de thuisserver een eigen sleutel:
umask 077
wg genkey > home_private.key
wg pubkey < home_private.key > home_public.key
De private key blijft thuis.
De home_public.key plaats je als PublicKey bij de betreffende peer op de VPS.
Thuisserver verbinden met de VPS
Maak op de thuisserver:
sudo nano /etc/wireguard/wg0.conf
Een eenvoudige configuratie kan zijn:
[Interface]
Address = 10.50.0.2/24
PrivateKey = PRIVATE_KEY_THUISSERVER
[Peer]
PublicKey = PUBLIC_KEY_VPS
Endpoint = 203.0.113.50:51820
AllowedIPs = 10.50.0.0/24
PersistentKeepalive = 25
Het cruciale verschil zit bij:
Endpoint = 203.0.113.50:51820
De thuisserver start zelf de verbinding naar de VPS.
Daarom hoeft de thuisrouter geen inkomende WireGuard-poort beschikbaar te maken.
Dat is precies waarom deze constructie achter CGNAT kan functioneren.
Waarom PersistentKeepalive bij CGNAT belangrijk kan zijn
WireGuard gebruikt UDP.
NAT-apparatuur bewaart niet onbeperkt de vertaling van een UDP-verbinding wanneer er geen verkeer plaatsvindt.
Daarom wordt bij een peer achter NAT vaak:
PersistentKeepalive = 25
gebruikt.
De thuisserver stuurt dan periodiek een klein pakket door de tunnel.
Hierdoor blijft de NAT-mapping actief en kan de VPS verkeer terugsturen via dezelfde bestaande verbinding.
WireGuard is bovendien ontworpen met endpoint roaming, waardoor peers veranderende externe endpointadressen kunnen verwerken. Dat past goed bij clients die achter NAT of op wisselende verbindingen zitten.
De tunnel automatisch starten
Op zowel VPS als thuisserver kun je WireGuard starten met:
sudo systemctl enable --now wg-quick@wg0
Controleer daarna:
sudo wg show
Op de VPS hoort bij de thuispeer uiteindelijk een recente:
latest handshake
te verschijnen.
Wanneer dat gebeurt, heeft de thuisserver ondanks CGNAT succesvol verbinding gemaakt met het publieke WireGuard-endpoint.
Daarmee is de eerste helft van de infrastructuur klaar.
Nu een laptop via de VPS laten verbinden
De laptop maakt rechtstreeks verbinding met de VPS.
Geef hem bijvoorbeeld WireGuard-adres:
10.50.0.3
Op de VPS voeg je toe:
[Peer]
PublicKey = PUBLIC_KEY_LAPTOP
AllowedIPs = 10.50.0.3/32
De laptopconfiguratie kan er ongeveer zo uitzien:
[Interface]
PrivateKey = PRIVATE_KEY_LAPTOP
Address = 10.50.0.3/32
[Peer]
PublicKey = PUBLIC_KEY_VPS
Endpoint = 203.0.113.50:51820
AllowedIPs = 10.50.0.0/24, 192.168.1.0/24
PersistentKeepalive = 25
Nu stuurt de laptop alleen verkeer naar het WireGuard-netwerk en thuisnetwerk door de VPN.
Normaal internetverkeer blijft via wifi of mobiel internet lopen.
Dit is een split-tunnelconfiguratie.
Routing op de thuisserver inschakelen
Als de laptop alleen de thuisserver zelf hoeft te bereiken, ben je bijna klaar.
Wil je ook andere apparaten binnen:
192.168.1.0/24
bereiken, dan moet de thuisserver verkeer tussen WireGuard en het lokale netwerk kunnen routeren.
Schakel IPv4 forwarding in:
sudo nano /etc/sysctl.d/99-wireguard-routing.conf
Plaats:
net.ipv4.ip_forward=1
Laad de instelling:
sudo sysctl --system
Controleer:
sysctl net.ipv4.ip_forward
Het resultaat hoort 1 te zijn.
De thuisserver mag nu IPv4-verkeer tussen interfaces doorsturen.
Waarom alleen routing nog niet altijd genoeg is
Stel dat de laptop:
10.50.0.3
een pakket naar de NAS stuurt:
192.168.1.20
De NAS ontvangt dat pakket.
Maar kent de NAS of thuisrouter ook een route terug naar:
10.50.0.0/24?
Vaak niet.
Het pakket komt dan wel aan, maar het antwoord weet niet hoe het terug naar de laptop moet.
Daarvoor bestaan twee normale oplossingen.
Je kunt een statische route op de thuisrouter toevoegen:
10.50.0.0/24 via 192.168.1.10
Dat is architectonisch netjes.
Wanneer je router geen eigen routes ondersteunt, kun je op de WireGuard-thuisserver NAT toepassen zodat apparaten binnen het LAN het verkeer zien alsof het van 192.168.1.10 afkomstig is.
De keuze hangt af van je router en netwerk.
VPN zonder port forwarding betekent niet zonder firewall
Dat je thuis geen poort hoeft te openen, betekent niet dat je niets hoeft te beveiligen.
De VPS is juist wél publiek bereikbaar.
Daar moet UDP 51820 worden toegestaan.
SSH-beheer van de VPS moet eveneens goed worden beschermd.
Gebruik bijvoorbeeld SSH-keys en beperk beheer waar mogelijk.
WireGuard zelf accepteert geen willekeurige gebruiker met alleen een gebruikersnaam en wachtwoord. Een peer moet over de juiste cryptografische sleutel beschikken.
Toch blijft de VPS een internetserver.
Updates, monitoring en firewallbeheer horen daarom bij de oplossing.
Kan ik hiervoor een bestaande VPS gebruiken?
Ja.
Heb je al een Linux-VPS, dan kan WireGuard vaak naast andere diensten draaien.
Technisch kun je bijvoorbeeld een VPS met websites of andere serverdiensten als centraal WireGuard-endpoint gebruiken.
Toch is een aparte kleine VPN-VPS soms handiger.
Je houdt networking dan los van productiehosting.
Een fout in routing of firewallregels heeft daardoor minder kans om de websites op dezelfde machine te beïnvloeden.
Bovendien blijft de VPN bereikbaar wanneer de webhostingserver onderhoud krijgt.
Voor een eenvoudig thuisnetwerk kan combineren echter prima werken.
Kan ik CGNAT gewoon door mijn provider laten uitschakelen?
Soms wel.
Daarom is dit eigenlijk de eerste oplossing die je moet onderzoeken.
Vraag de internetprovider of een publiek IPv4-adres beschikbaar is.
Bij sommige abonnementen is dat standaard mogelijk. Bij andere providers is een zakelijk abonnement of extra optie nodig.
Wanneer je een echt publiek IPv4-adres krijgt, kun je WireGuard weer op de traditionele manier thuis aanbieden.
Je router ontvangt dan het openbare adres en kan UDP-verkeer rechtstreeks naar de VPN-server forwarden.
Dat is eenvoudiger dan een extra VPS wanneer je de VPN uitsluitend voor toegang tot thuis nodig hebt.
Een statisch publiek IPv4-adres is niet altijd noodzakelijk
Voor een traditionele VPN thuis heb je vooral een publiek bereikbaar adres nodig.
Het adres hoeft niet per se voor altijd statisch te blijven.
Wanneer je provider een dynamisch publiek IPv4-adres levert, kan Dynamic DNS het probleem van wijzigingen oplossen.
Een hostname zoals:
vpn.thuisdomein.nl
wordt automatisch aangepast wanneer het thuis-IP verandert.
CGNAT is fundamenteel anders.
Dynamic DNS kan daar niet ineens een niet-publiek WAN-adres publiek bereikbaar maken.
Een hostname lost routing niet op.
Dit onderscheid is belangrijk.
VPN achter CGNAT via IPv6
Er bestaat nog een mogelijke route die regelmatig wordt vergeten: IPv6.
Een provider kan IPv4 via CGNAT leveren en tegelijkertijd een publiek IPv6-prefix aanbieden.
In dat geval kan een thuisserver mogelijk rechtstreeks via IPv6 bereikbaar zijn.
Je hoeft dan voor WireGuard niet per se door de CGNAT IPv4-laag.
Wel moet de client waarmee je onderweg verbinding maakt eveneens bruikbare IPv6-connectiviteit hebben.
Daarnaast moet de IPv6-firewall correct worden ingesteld.
Bij IPv6 gebruik je normaal geen port forwarding op dezelfde manier als bij NAT voor IPv4. Je geeft het apparaat een routable IPv6-adres en bepaalt met de firewall welk inkomend verkeer is toegestaan.
Dat kan een elegante oplossing zijn, maar alleen wanneer beide kanten IPv6 goed ondersteunen.
Waarom IPv6 niet automatisch de eenvoudigste oplossing is
In theorie lost IPv6 het tekort aan publieke adressen op.
In de praktijk zijn niet alle netwerken volledig dual stack.
Stel dat je thuisserver alleen via IPv6 bereikbaar is.
Je zit later op een hotelnetwerk dat alleen bruikbaar IPv4 levert.
Dan kan die client niet zonder aanvullende vertaling rechtstreeks naar het IPv6-only WireGuard-endpoint verbinden.
Een VPS met zowel IPv4 als IPv6 kan dat probleem vermijden.
Die vormt één centraal bereikbaar punt voor verschillende soorten verbindingen.
Daarom blijft een VPS-oplossing vaak praktisch, zelfs wanneer thuis IPv6 beschikbaar is.
WireGuard achter CGNAT met NAT traversal
Een andere aanpak is software die probeert rechtstreeks door NAT heen verbindingen op te bouwen.
Daarbij proberen beide apparaten via uitgaande verbindingen een directe peer-to-peerroute tot stand te brengen.
Dat lukt bij veel NAT-configuraties, maar niet altijd.
Hoe streng de verschillende NAT-apparaten aan beide kanten zijn, bepaalt of een directe verbinding mogelijk is.
Wanneer beide kanten zich achter moeilijke NAT-configuraties bevinden, kan een relay nodig zijn.
Dit is het probleem dat systemen zoals Tailscale proberen te automatiseren.
Tailscale achter CGNAT
Tailscale bouwt een mesh-netwerk bovenop WireGuard.
Het systeem probeert apparaten eerst rechtstreeks peer-to-peer met elkaar te verbinden door NAT-traversal toe te passen.
Daarvoor hoeven in veel situaties geen handmatige firewall- of port-forwardingregels te worden ingesteld.
Lukt rechtstreeks verbinden niet, bijvoorbeeld door een strenge NAT-configuratie, dan kan Tailscale verkeer relayeren.
De dienst gebruikt hiervoor onder meer DERP-relays.
Het verkeer dat via zo’n DERP-server loopt blijft end-to-end met WireGuard versleuteld; de relay stuurt de versleutelde pakketten door zonder de WireGuard-private keys te hebben.
Dat maakt Tailscale aantrekkelijk wanneer je vooral wilt dat apparaten elkaar bereiken zonder zelf alle NAT- en routingproblemen te beheren.
Is Tailscale hetzelfde als zelf WireGuard hosten?
Niet helemaal.
Bij traditioneel WireGuard beheer je zelf de peers, endpoints, routes en serverconfiguratie.
Bij Tailscale wordt een groot deel van de verbindingstechniek en coördinatie geautomatiseerd.
Tailscale probeert een directe verbinding op te bouwen. Wanneer dat niet mogelijk is, kan het terugvallen op peer relays of DERP. Directe verbindingen geven volgens de documentatie de beste prestaties, terwijl relaying extra netwerkafstand en daarmee vaak minder goede prestaties kan geven.
Wil je maximale controle en een volledig eigen publiek endpoint, dan kan de VPS/WireGuard-route aantrekkelijker zijn.
Wil je vooral zo weinig mogelijk handmatig netwerkbeheer, dan is een mesh-VPN een alternatief.
Wat is Headscale?
Wie het WireGuard/Tailscale-principe interessant vindt maar meer onderdelen zelf wil beheren, komt mogelijk Headscale tegen.
Het idee hiervan is dat je een eigen control server gebruikt voor compatibele clients.
Dat is technisch uitgebreider dan een simpele WireGuard-server.
Daarom is het niet automatisch de beste oplossing voor één NAS en één laptop.
Voor grotere omgevingen waar centrale apparaatregistratie belangrijk is, kan zo’n architectuur interessanter worden.
Het belangrijkste is dat je eerst bepaalt welk probleem je probeert op te lossen.
Gebruik geen ingewikkeld mesh-platform wanneer één VPS met drie WireGuard-peers hetzelfde doel eenvoudiger bereikt.
Kun je Cloudflare Tunnel gebruiken achter CGNAT?
Voor webapplicaties bestaat nog een andere categorie oplossingen: outbound tunnels.
Daarbij draait thuis een connector die zelf een verbinding met een externe infrastructuur opent.
Daardoor hoef je thuis geen inkomende poort publiek beschikbaar te stellen.
Dit kan interessant zijn wanneer je bijvoorbeeld één interne webapplicatie beschikbaar wilt maken.
Het is echter niet automatisch hetzelfde als een algemene WireGuard-VPN waarmee je volledige private netwerken routeert.
Daarom moet je onderscheid maken tussen:
een specifieke webservice publiceren
en:
volledige netwerktoegang tot je LAN bieden.
Voor toegang tot meerdere interne IP-adressen, SSH, NAS en andere netwerkdiensten is een echte VPN- of private-networkoplossing vaak logischer.
VPN achter CGNAT voor een NAS
Een NAS is een veelvoorkomende reden waarom mensen dit probleem tegenkomen.
Thuis werkt bijvoorbeeld:
192.168.1.20
prima.
Onderweg wil je bestanden openen, maar je wilt het beheerportaal van de NAS liever niet rechtstreeks voor heel internet publiceren.
Een VPN is dan een veel betere netwerkarchitectuur.
Bij CGNAT bouwt de NAS of een aparte thuisserver de uitgaande tunnel naar de VPS.
Jouw laptop maakt eveneens verbinding met die VPS.
Daarna kun je de NAS via zijn normale interne adres benaderen.
Voor de NAS lijkt het alsof de gebruiker via een ander intern gerouteerd netwerk binnenkomt.
Je hoeft de NAS zelf dus geen openbaar IPv4-adres te geven.
Raspberry Pi of mini-pc als VPN-router
Je hoeft WireGuard niet noodzakelijk rechtstreeks op de NAS te installeren.
Een kleine Linux-machine kan als VPN-router tussen WireGuard en het LAN functioneren.
Bijvoorbeeld een mini-pc die permanent draait.
Deze machine krijgt thuis:
192.168.1.10
en binnen WireGuard:
10.50.0.2
Hij bouwt automatisch de tunnel met de VPS op.
Alle routes naar 192.168.1.0/24 lopen vervolgens via deze computer.
Dat is handig wanneer je verschillende apparaten wilt bereiken die zelf geen VPN-software ondersteunen.
Je hoeft de VPN-client dan niet op iedere printer, camera, NAS of ander intern apparaat te installeren.
VPN achter CGNAT voor Home Assistant of interne dashboards
Hetzelfde principe werkt voor interne webapplicaties.
Stel dat een dashboard alleen thuis beschikbaar is op:
192.168.1.30:8123
Je hoeft daarvoor niet een openbare reverse proxy te bouwen wanneer alleen jij of enkele medewerkers toegang nodig hebben.
Verbind eerst met het VPN.
Daarna benader je gewoon het interne adres.
De applicatie blijft daardoor binnen het private netwerk.
Dit kan veiliger en eenvoudiger zijn dan iedere interne dienst afzonderlijk vanaf internet publiceren.
Authenticatie binnen de applicatie blijft overigens belangrijk.
Een VPN is een extra netwerklaag, geen vervanging voor gebruikersbeveiliging.
Wat als je twee netwerken achter CGNAT wilt verbinden?
Ook dat kan met een centrale VPS.
Stel dat locatie A en locatie B beide achter CGNAT zitten.
Geen van beide locaties kan een normale inkomende VPN-server aanbieden.
Beide locaties kunnen echter zelf een uitgaande WireGuard-verbinding met dezelfde VPS starten.
De architectuur wordt:
Locatie A → VPS ← Locatie B
De VPS kent de routes naar beide lokale netwerken.
Bijvoorbeeld:
Locatie A:
192.168.10.0/24
Locatie B:
192.168.20.0/24
Vervolgens kan de VPS verkeer tussen beide WireGuard-peers routeren.
Zo bouw je feitelijk een site-to-site VPN waarbij geen van beide locaties een publiek IPv4-adres nodig heeft.
Dat is een bijzonder nuttige toepassing van een centrale VPN-hub.
CGNAT en IP-camera’s
Het feit dat CGNAT normale port forwarding moeilijk maakt, kan soms juist een voordeel zijn.
Apparaten in het thuisnetwerk zijn hierdoor minder eenvoudig rechtstreeks vanaf IPv4-internet te benaderen.
Het is daarom meestal geen goed idee om CGNAT uitsluitend te willen omzeilen zodat allerlei losse apparaatpoorten publiek kunnen worden geopend.
Gebruik liever één gecontroleerde VPN-toegang.
Daarmee maak je eerst een geauthenticeerde versleutelde verbinding.
Daarna bereik je interne apparatuur via het LAN.
Dat levert een veel overzichtelijker aanvalsoppervlak op dan voor ieder apparaat een aparte publieke poort.
VPN achter CGNAT en gaming
CGNAT wordt ook regelmatig genoemd bij online games.
Dat is echter een andere gebruikssituatie dan een eigen zakelijke VPN.
Games kunnen last hebben van bepaalde NAT-types en inkomende peer-to-peerverbindingen.
Een VPS-tunnel kan technisch bepaalde routingmogelijkheden creëren, maar voegt ook extra latency toe.
Daarom is een zelfgebouwde VPN niet automatisch de beste oplossing voor games.
Wanneer het uitsluitend om gameconnectiviteit gaat, is het verstandiger eerst te onderzoeken of de internetprovider een publiek IPv4-adres beschikbaar kan stellen.
Voor externe toegang tot eigen servers en netwerken is de VPS-oplossing veel duidelijker.
Waarom DMZ op je eigen router CGNAT niet oplost
Routers hebben soms een instelling genaamd DMZ host.
Daarmee wordt veel inkomend verkeer dat je eigen router ontvangt naar één intern apparaat gestuurd.
Maar achter CGNAT bereikt het ongewenste inkomende IPv4-verkeer je eigen router in de eerste plaats niet.
De blokkade zit vóór jouw netwerk.
Een DMZ-instelling verandert niets aan de NAT-router van je provider.
Daarom zijn combinaties van:
DMZ,
UPnP,
port forwarding,
en willekeurige firewallregels
geen echte oplossing voor de provider-NAT-laag.
Je moet een publiek adres krijgen of een verbinding gebruiken die vanuit jouw netwerk naar buiten wordt opgebouwd.
UPnP lost CGNAT evenmin op
UPnP kan binnen je eigen netwerk automatisch een port-forwardingregel op de router laten maken.
Dat is handig voor bepaalde applicaties.
Maar ook deze techniek beheert alleen de NAT-laag waar je zelf controle over hebt.
Als daarboven nog een carrier-NAT zit, kan UPnP die niet zomaar configureren.
Daarom kan een applicatie melden dat een poort succesvol is geopend terwijl hij vanaf het openbare internet alsnog niet bereikbaar is.
Dat is een belangrijke aanwijzing om verder te kijken dan de eigen router.
Double NAT is niet altijd CGNAT
Het is ook mogelijk dat je twee eigen routers achter elkaar hebt staan.
Bijvoorbeeld:
providerrouter → eigen router → thuisnetwerk
Dan heb je eveneens twee NAT-lagen.
Het verschil is dat je bij beide apparaten mogelijk zelf de instellingen kunt aanpassen.
Je kunt dan bijvoorbeeld de providerrouter in bridge-modus zetten of op beide routers port forwarding configureren.
Bij CGNAT is de bovenste NAT-laag eigendom van de internetprovider en heb je die controle niet.
Controleer dus eerst of de extra NAT daadwerkelijk bij de provider zit.
Misschien staat er gewoon een tweede router in je meterkast.
Hoe test je de WireGuard-route via de VPS?
Begin klein.
Controleer eerst op de VPS:
sudo wg show
De thuispeer moet een recente handshake tonen.
Ping daarna vanaf de VPS:
ping 10.50.0.2
Werkt dat, dan is de VPS-tot-thuis-tunnel actief.
Verbind vervolgens de laptop en test:
ping 10.50.0.1
Daarna:
ping 10.50.0.2
Pas wanneer die verbindingen werken, test je een LAN-apparaat:
ping 192.168.1.20
Door laag voor laag te testen zie je precies waar routing faalt.
Dat is veel effectiever dan alle firewall- en WireGuard-instellingen tegelijk wijzigen.
WireGuard handshake werkt, maar thuisnetwerk niet
Wanneer de laptop zowel de VPS als 10.50.0.2 kan bereiken, werkt WireGuard zelf.
Kan 192.168.1.20 vervolgens niet worden bereikt, dan zit het probleem waarschijnlijk in routing tussen de thuisserver en het LAN.
Controleer eerst IP forwarding.
Daarna controleer je of de thuisserver een interface binnen 192.168.1.0/24 heeft.
Vervolgens moet er een correcte retourroute bestaan.
Een pakket moet namelijk niet alleen van laptop naar NAS kunnen gaan.
Het antwoord van de NAS moet ook terug kunnen naar 10.50.0.3.
Juist die retourroute wordt bij VPN-configuraties vaak vergeten.
Waarom NAT thuis eenvoudiger kan zijn dan een statische route
Niet iedere consumentenrouter ondersteunt eigen statische routes.
In dat geval kun je verkeer vanuit WireGuard op de thuisserver maskeren naar het lokale LAN-adres.
Een NAS ziet het verzoek dan bijvoorbeeld als afkomstig van:
192.168.1.10
in plaats van:
10.50.0.3
De NAS weet automatisch hoe hij naar 192.168.1.10 moet antwoorden, omdat dit in hetzelfde lokale subnet ligt.
Het nadeel is dat interne apparaten niet meer direct zien welke oorspronkelijke VPN-client de verbinding begon.
Met echte routes blijft die informatie beter behouden.
Voor een klein thuisnetwerk kan NAT echter eenvoudiger zijn.
CGNAT en een dynamisch publiek adres zijn twee verschillende problemen
Dit onderscheid is belangrijk genoeg om nogmaals te benadrukken.
Dynamisch publiek IPv4:
je bent wel publiek bereikbaar, maar het adres kan veranderen.
Oplossing:
Dynamic DNS.
CGNAT:
je router heeft geen eigen rechtstreeks publiek IPv4-endpoint voor gewone inkomende verbindingen.
Oplossing:
publiek IP aanvragen, IPv6 gebruiken, NAT traversal toepassen of een externe server/tunnel inzetten.
Een DDNS-dienst lost daarom geen CGNAT op.
Hij kan alleen een hostname bijwerken naar een adres dat technisch bereikbaar moet zijn.
Welke oplossing is het beste?
Voor een eenvoudige thuissituatie zou ik deze beslisvolgorde gebruiken.
Vraag eerst of je provider een publiek IPv4-adres kan leveren.
Kan dat zonder grote nadelen? Dan is dat meestal de eenvoudigste route voor een traditionele WireGuard-server thuis.
Kan dat niet, maar heb je goed publiek IPv6 aan beide kanten? Dan kan een WireGuard-endpoint via IPv6 interessant zijn.
Wil je vooral enkele apparaten gemakkelijk met elkaar laten communiceren en zo weinig mogelijk routing beheren? Dan kan een NAT-traversal/mesh-oplossing geschikt zijn.
Wil je volledige controle, je eigen publieke endpoint, meerdere LAN-routes of twee locaties koppelen? Dan is een VPS als centrale WireGuard-hub vaak de meest flexibele self-hosted aanpak.
Is een VPS als tussenstation langzaam?
Er komt een extra netwerkstap bij.
Verkeer van je laptop naar huis gaat bijvoorbeeld:
laptop → VPS → thuis
De latency is daarom meestal hoger dan bij een perfecte directe peer-to-peerverbinding.
Kies een VPS dicht bij de locaties die hem gebruiken.
Wanneer zowel jij als je thuisverbinding in Nederland zijn, is een VPS in een Nederlands datacenter een logische keuze.
Bij een mesh-systeem kan een directe verbinding sneller zijn wanneer NAT traversal slaagt.
Wanneer een relay nodig is, ontstaat eveneens een extra tussenstation. Tailscale geeft zelf aan dat relayed connections doorgaans minder goede prestaties hebben dan directe verbindingen vanwege de extra route en relaybeperkingen.
Hoeveel VPS-capaciteit heb je nodig?
Voor alleen WireGuard en enkele gebruikers hoeft een VPS niet bijzonder zwaar te zijn.
Opslag is nauwelijks relevant.
Netwerksnelheid is belangrijker.
Stuur je bijvoorbeeld grote NAS-back-ups door de tunnel, dan kan honderden megabits per seconde aan netwerkverkeer nodig zijn.
Gebruik je de tunnel alleen voor een beheerpaneel en enkele documenten, dan is de belasting veel kleiner.
Ook het maandelijkse dataverkeer van het VPS-pakket telt mee.
Verkeer van laptop naar thuis loopt via de VPS en verbruikt daar dus bandbreedte.
Bij intensief gebruik moet je dit meenemen in de keuze van de hostingprovider.
VPN achter CGNAT beveiligen
De thuisserver hoeft niet publiek bereikbaar te zijn, maar de VPS wel.
Daarom blijft serverbeveiliging noodzakelijk.
Houd Ubuntu actueel.
Beveilig SSH.
Laat alleen de benodigde poorten openstaan.
Gebruik voor ieder apparaat een eigen WireGuard-key.
Raakt een laptop kwijt, verwijder dan alleen diens public key.
De andere gebruikers blijven functioneren.
Bewaar bovendien de VPS-private key en serverconfiguratie in een beveiligde back-up.
Wie de private sleutel in handen krijgt, heeft gevoelige cryptografische informatie van de VPN-infrastructuur.
Wat gebeurt er als de VPS uitvalt?
Bij deze architectuur is de VPS het centrale verbindingspunt.
Valt de VPS uit, dan kan de externe laptop niet meer via die route thuis komen.
Voor persoonlijk gebruik is dat meestal acceptabel.
Voor zakelijke toepassingen kun je een tweede WireGuard-hub gebruiken.
De thuisserver kan bijvoorbeeld een tweede uitgaande tunnel onderhouden naar een andere VPS.
Clients krijgen dan een primair en secundair profiel.
Daarmee kun je dezelfde principes uit server failover toepassen op de VPN-infrastructuur.
Hoe belangrijker de verbinding, hoe meer redundantie zin krijgt.
VPN achter CGNAT voor zakelijke locaties
CGNAT komt niet alleen thuis voor.
Mobiele verbindingen en bepaalde zakelijke verbindingen kunnen eveneens achter NAT-infrastructuur zitten.
Stel dat een tijdelijke vestiging via 5G internet gebruikt.
Je krijgt daar misschien geen eigen publiek IPv4-adres.
Toch kan een router op die locatie zelf een WireGuard-tunnel naar een centrale VPS openen.
Vanaf het hoofdkantoor kun je vervolgens via die tunnel apparaten in de tijdelijke vestiging bereiken.
Daardoor is een publiek IP op iedere afzonderlijke locatie niet noodzakelijk.
Dit maakt het hub-and-spoke-model interessant voor verspreide netwerken.
VPN achter CGNAT en mobiel internet
Mobiele netwerken zijn een goed voorbeeld van omgevingen waar je niet moet aannemen dat normale port forwarding beschikbaar is.
Een router met een 4G- of 5G-simkaart kan prima uitgaand internet hebben, terwijl inkomend IPv4-verkeer niet rechtstreeks naar die router kan worden gestuurd.
Dezelfde uitgaande-tunneltechniek werkt hier goed.
De mobiele router of een apparaat erachter maakt zelf verbinding met de VPS.
Omdat die verbinding van binnen naar buiten wordt gestart, hoeft de mobiele provider geen inkomende VPN-poort naar jou door te sturen.
Voor mobiele of tijdelijke locaties kan dit veel praktischer zijn dan proberen een publiek IPv4-adres af te dwingen.
VPN achter CGNAT: conclusie
Een VPN achter CGNAT werkt prima, maar je moet stoppen met denken alsof je thuisrouter rechtstreeks aan het openbare IPv4-internet hangt.
Dat is namelijk precies wat bij Carrier-Grade NAT niet het geval is.
Normale port forwarding kan alleen de apparatuur configureren waar jij controle over hebt. De extra NAT-laag van de internetprovider blijft bestaan.
De oplossing is daarom meestal één van vier routes: een echt publiek adres aanvragen, rechtstreeks IPv6 gebruiken, NAT traversal inzetten of een publiek bereikbare server als centraal tussenpunt gebruiken.
Voor een volledig zelfbeheerde omgeving is een VPS met WireGuard bijzonder flexibel.
De thuisserver start zelf een uitgaande tunnel naar de VPS. Daardoor maakt het niet uit dat gewone inkomende IPv4-verbindingen via CGNAT niet mogelijk zijn.
Vervolgens kunnen laptops, telefoons of andere locaties verbinding maken met dezelfde VPS en via die route het private netwerk bereiken.
Zo behoud je controle over routing, sleutels en infrastructuur zonder thuis een publiek IPv4-adres nodig te hebben.
VPN achter CGNAT laten inrichten door Sanum
Sanum kan een VPN achter CGNAT inrichten wanneer een thuis-, kantoor-, mobiele of andere internetverbinding geen rechtstreeks publiek IPv4-adres heeft.
Daarbij kan een WireGuard-hub op een VPS worden gebruikt waar de locatie zelf een uitgaande tunnel mee onderhoudt.
Vervolgens kunnen geautoriseerde apparaten via dezelfde infrastructuur interne servers, NAS-systemen of andere private diensten bereiken.
Ook routing tussen meerdere locaties is mogelijk.
Daarbij moet niet alleen WireGuard correct worden ingesteld. Retourroutes, firewalls, IP forwarding, DNS en monitoring spelen eveneens een rol.
Voor zakelijke omgevingen kan daarnaast een tweede VPN-endpoint worden ingericht wanneer afhankelijkheid van één VPS ongewenst is.
Kun je door CGNAT geen VPN-server, NAS of bedrijfsnetwerk vanaf buiten bereiken? Sanum kan onderzoeken welke netwerkconstructie aanwezig is en een passende WireGuard- of VPS-oplossing inrichten zonder onnodig interne diensten rechtstreeks op internet te publiceren.
Veelgestelde vragen over VPN achter CGNAT
Wat is CGNAT?
CGNAT staat voor Carrier-Grade Network Address Translation. Een internetprovider kan hiermee meerdere klanten gebruik laten maken van gedeelde publieke IPv4-adressen. RFC 6598 reserveert hiervoor onder andere 100.64.0.0/10.
Waarom werkt port forwarding niet achter CGNAT?
Omdat je eigen router niet de enige NAT-router tussen het lokale netwerk en internet is. Er bevindt zich nog een NAT-laag bij de provider waar je zelf geen port-forwardingregel kunt instellen.
Hoe weet ik of ik CGNAT heb?
Vergelijk het WAN IPv4-adres van je eigen router met je zichtbare publieke IPv4-adres. Een WAN-adres binnen 100.64.0.0/10 is een duidelijke aanwijzing voor gedeelde provideradresruimte.
Kan WireGuard achter CGNAT werken?
Ja. Een apparaat achter CGNAT kan zelf een uitgaande WireGuard-verbinding naar een publiek bereikbare VPS openen. Andere clients kunnen vervolgens via die VPS terug naar het netwerk worden gerouteerd.
Heb ik port forwarding nodig voor WireGuard achter CGNAT?
Niet wanneer de locatie achter CGNAT zelf een uitgaande tunnel naar een VPS maakt. De VPS moet wel publiek bereikbaar zijn op de gekozen WireGuard UDP-poort.
Kan ik CGNAT omzeilen met Dynamic DNS?
Nee. Dynamic DNS kan een veranderend publiek IP-adres aan een hostname koppelen, maar maakt een niet-publiek CGNAT-adres niet rechtstreeks vanaf internet bereikbaar.
Kan ik mijn provider vragen CGNAT uit te zetten?
Sommige internetproviders kunnen een publiek IPv4-adres leveren. De beschikbaarheid en eventuele kosten verschillen per provider en abonnement.
Kan IPv6 CGNAT oplossen?
Wanneer je provider een publiek routable IPv6-prefix levert, kan een WireGuard-server mogelijk rechtstreeks via IPv6 bereikbaar zijn. De externe client moet dan wel bruikbare IPv6-connectiviteit hebben.
Kan ik mijn NAS bereiken achter CGNAT?
Ja. Een thuisserver of VPN-router kan een uitgaande tunnel naar een VPS openen. Via die route kun je vervolgens private LAN-adressen van bijvoorbeeld een NAS bereiken.
Kan Tailscale achter CGNAT werken?
Ja. Tailscale probeert met NAT traversal directe verbindingen te maken en kan terugvallen op relayverbindingen wanneer direct peer-to-peer niet mogelijk is.
Is Tailscale sneller dan een VPS met WireGuard?
Dat hangt van de netwerkroute af. Een succesvolle directe peer-to-peerverbinding kan een kortere route hebben. Wanneer Tailscale moet relayeren ontstaat extra latency. Een eigen VPS biedt juist een voorspelbare centrale route.
Kunnen twee locaties die allebei CGNAT hebben met elkaar verbinden?
Ja. Beide locaties kunnen uitgaande WireGuard-tunnels naar dezelfde VPS maken. De VPS routeert vervolgens verkeer tussen de twee private netwerken.
Werkt dit ook via 4G of 5G?
Ja. Zolang de mobiele verbinding uitgaand internet toestaat, kan een apparaat meestal zelf een WireGuard-verbinding met een publiek VPS-endpoint initiëren.
Is een VPS verplicht?
Nee. Een publiek IPv4-adres, geschikte IPv6-connectiviteit of NAT-traversaloplossing kan de VPS overbodig maken. Een VPS is vooral een flexibele oplossing wanneer je zelf volledige controle over het publieke endpoint wilt.
Waarom wordt PersistentKeepalive gebruikt?
Een peer achter NAT kan periodiek een klein pakket versturen zodat de NAT-mapping actief blijft. Hierdoor kan verkeer gemakkelijker via de bestaande UDP-route terug naar de peer worden gestuurd.
Is een VPN achter CGNAT veilig?
CGNAT zelf maakt een VPN niet veilig of onveilig. De beveiliging hangt onder andere af van WireGuard-keys, serverupdates, firewallregels en beheer van apparaten en gebruikers.
Wat is beter: een poort publiek openen of toegang via VPN?
Voor interne beheerdiensten, NAS-systemen en vergelijkbare private toepassingen is één gecontroleerde VPN-toegang vaak overzichtelijker dan meerdere diensten afzonderlijk rechtstreeks op internet publiceren.
Kan ik dezelfde VPS ook voor site-to-site VPN gebruiken?
Ja. De VPS kan als centrale WireGuard-hub routes onderhouden naar verschillende private netwerken. Dat is precies de basis voor een site-to-siteopstelling waarbij één of beide locaties achter CGNAT kunnen staan.
