VPN server achter NAT

[c-nan]

In het buitenland wil ik een VPN server plaatsen, op die locatie kan ik geen port forwards instellen. De VPN server komt achter een NAT te hangen. Dus direct met de VPN server verbinden kan niet.

Ik heb een VPS met een dedicated publiek IPv4 adres.

Wens is om vanuit Nederland met meerdere clients gebruik te maken van de VPS server. Voornamelijk tijdens het browsen op een Mac device (MacBook, Mac Mini, etc).

Volgens mij kan het volgende werken:
Ik heb al een Raspberry Pi tot mijn beschikking, dus deze kan ik als VPN server inrichten. Op de rPi installeer ik OpenVPN.
De rPi zet vervolgens een reverse SSH tunnel op naar mijn VPS:

code:

ssh -N -R 1194:localhost:1194 [e-mail]

De clients zetten een VPN verbinding op naar de VPS, maar doordat poort 1194 wordt doorgesluisd naar de rPi komen de clients uiteindelijk op de rPi uit.

Wat vinden jullie hiervan? Prima? Zou je het anders doen? Hoe zorg ik ervoor dat de SSH tunnel altijd up is, ook na een reboot van de VPS of van de rPi? Keuze voor OpenVPN oke, of is er tegenwoordig iets anders wat beter werkt (ook via een reverse ssh tunnel)? Welk OS op de rPi (Raspberry Pi OS of iets anders)?

[FredvZ]

Waarom richt je die VPS niet in als VPN-server?

[c-nan]

FredvZ schreef op vrijdag 8 augustus 2025 @ 22:28:
Waarom richt je die VPS niet in als VPN-server?

De VPS zit in land A, de clients in land B. Ik wil de VPN server opzetten in land C.
In land C heb ik al internet waar een ik een Raspberry Pi kan plaatsen.

[FrankHe]

Als je werkelijk niet een NAT forward rule kunt aanmaken dan rest er één mogelijkheid, je verkeer doorrouteren naar het apparaat op locatie A. Dit maak het wel een stuk ingewikkelder en potentieel minder stabiel.

Je zet een endpoint (VPN-server) in Nederland en al je clients laat je daarmee verbinden. Vervolgens maak je van het apparaat op locatie A een VPN client die met dezelfde VPN-server in Nederland laat verbinden. vervolgend laat je al het verkeer van de overige clients door de tunnel sturen naar de VPN-client op locatie A. Niet ideaal maar het kan wel.

Beter is het als je éénmalig één NAT forward kunt instellen op locatie A.

Je geeft zelf al aan met een reverse SSH-tunnel te kunnen werken. Zoals gezegd werkt het maar of het altijd even stabiel gaat zijn hangt van heel veel factoren af.

[ Voor 11% gewijzigd door FrankHe op 08-08-2025 22:34 ]

[FredvZ]

c-nan schreef op vrijdag 8 augustus 2025 @ 22:30:
[...]

De VPS zit in land A, de clients in land B. Ik wil de VPN server opzetten in land C.
In land C heb ik al internet waar een ik een Raspberry Pi kan plaatsen.

Ook dan blijft de vraag staan

Clients in land B krijgen de VPN als default gateway
Op de server routeer je al het verkeer naar je Raspberry Pi
Op de Raspberry Pi routeer je het verkeer uit de VPN het internet op.

[c-nan]

FrankHe schreef op vrijdag 8 augustus 2025 @ 22:31:
Als je werkelijk niet een NAT forward rule kunt aanmaken dan rest er één mogelijkheid, je verkeer doorrouteren naar het apparaat op locatie A. Dit maak het wel een stuk ingewikkelder en potentieel minder stabiel.

Je zet een endpoint (VPN-server) in Nederland en al je clients laat je daarmee verbinden. Vervolgens maak je van het apparaat op locatie A een VPN client die met dezelfde VPN-server in Nederland laat verbinden. vervolgend laat je al het verkeer van de overige clients door de tunnel sturen naar de VPN-client op locatie A. Niet ideaal maar het kan wel.

Klinkt alsof dit ook kan werken, maar ik weet niet hoe stabiel dit gaat zijn. Iets om uit te zoeken.

Beter is het als je éénmalig één NAT forward kunt instellen op locatie A.

Is helaas niet mogelijk.

Je geeft zelf al aan met een reverse SSH-tunnel te kunnen werken. Zoals gezegd werkt het maar of het altijd even stabiel gaat zijn hangt van heel veel factoren af.

Daarom dit topic, wellicht dat er betere/veiligere/stabielere opties zijn.

[c-nan]

FredvZ schreef op vrijdag 8 augustus 2025 @ 22:38:
[...]

Ook dan blijft de vraag staan

Clients in land B krijgen de VPN als default gateway
Op de server routeer je al het verkeer naar je Raspberry Pi
Op de Raspberry Pi routeer je het verkeer uit de VPN het internet op.

Dat is het idee ja, ik ben dus op zoek naar de meest stabiele oplossing. Is dat dus met een reverse SSH tunnel op de Raspberry Pi naar de VPS ? Of zijn er andere betere/slimmere manieren?

[mrmrmr]

c-nan schreef op vrijdag 8 augustus 2025 @ 22:20:
Hoe zorg ik ervoor dat de SSH tunnel altijd up is, ook na een reboot van de VPS of van de rPi?

Je kan de verbinding via de command line starten in een loop. Of je test vanuit een script de verbinding en breekt die af als het niet meer werkt en start een nieuwe. Je kan testen of de poort vrij is.

[FredvZ]

c-nan schreef op vrijdag 8 augustus 2025 @ 22:44:
Dat is het idee ja, ik ben dus op zoek naar de meest stabiele oplossing. Is dat dus met een reverse SSH tunnel op de Raspberry Pi naar de VPS ? Of zijn er andere betere/slimmere manieren?

Het is stabieler als je de VPN server op je VPS en je raspberry pi als óók client verbindt ipv ssh te gebruiken.

[FrankHe]

c-nan schreef op vrijdag 8 augustus 2025 @ 22:44:
[...]

Dat is het idee ja, ik ben dus op zoek naar de meest stabiele oplossing. Is dat dus met een reverse SSH tunnel op de Raspberry Pi naar de VPS ? Of zijn er andere betere/slimmere manieren?

In mijn ervaring zijn WireGuard VPN-tunnels het meest betrouwbaar. Goede uptime en in het geval van een onderbreking herstellen ze zichzelf binnen enkele seconden weer. Een SSH-tunnel heeft doorgaans langer nodig om weer te herstellen.

Ik weet niet hoeveel processorkracht de Pi heeft die je in gedachte hebt? Wanneer een enigszins acceptabele datadoorvoer van belang is dan zou ik daar nog even goed naar kijken. Een beetje web browsen kan van alles betekenen. Webmail en websites bekijken is web browsen maar ook video's streamen valt onder web browsen. De ene video is de andere niet.

Heb je genoeg aan 20 Mbps of moet het tenminste 100 Mbps aankunnen? Of kijk je eerder naar een doorvoer van 500 Mbps? Bedenk ook dat de data via dezelfde NIC het apparaat in en uit gaat en dat de NIC aan de kant van de CPU niet altijd de beschikking heeft over de volledig bandbreedte. Bij een (oudere) Pi is dat nog wel eens USB 2.0 snelheid, maximaal 480 Mbps, als je dat überhaupt al haalt, ik denk dat de CPU veel eerder een beperkende factor gaat zijn.

[peize9]

Van wat ik lees is Wireguard het handigste. Gebruikte wij ook toen we van binnen naar buiten het schoolnetwerk moesten om ipv6 in het lab te krijgen

Ik heb wel even de vraag, ga je wonen in het buitenland of is het een vakantie ding? Wat is de usecase?

Heb je trouwens ook al nagedacht over ipv6? Als je dat op A kan krijgen kan je misschien nog kijken naar een soort tunnel die v4 traffic meeneemt over v6 of iets in die richting, maar daar heb ik me nog niet echt op ingelezen.

[c-nan]

FrankHe schreef op zaterdag 9 augustus 2025 @ 09:58:
[...]

In mijn ervaring zijn WireGuard VPN-tunnels het meest betrouwbaar. Goede uptime en in het geval van een onderbreking herstellen ze zichzelf binnen enkele seconden weer. Een SSH-tunnel heeft doorgaans langer nodig om weer te herstellen.

Ik weet niet hoeveel processorkracht de Pi heeft die je in gedachte hebt? Wanneer een enigszins acceptabele datadoorvoer van belang is dan zou ik daar nog even goed naar kijken. Een beetje web browsen kan van alles betekenen. Webmail en websites bekijken is web browsen maar ook video's streamen valt onder web browsen. De ene video is de andere niet.

Heb je genoeg aan 20 Mbps of moet het tenminste 100 Mbps aankunnen? Of kijk je eerder naar een doorvoer van 500 Mbps? Bedenk ook dat de data via dezelfde NIC het apparaat in en uit gaat en dat de NIC aan de kant van de CPU niet altijd de beschikking heeft over de volledig bandbreedte. Bij een (oudere) Pi is dat nog wel eens USB 2.0 snelheid, maximaal 480 Mbps, als je dat überhaupt al haalt, ik denk dat de CPU veel eerder een beperkende factor gaat zijn.

Met WG haal je volgens mij hogere throughput, maar mijn verwachting is dat het via een reverse ssh tunnel niet gaat werken.

Voornamelijk webbrowsen, en incidenteel video streamen.

[c-nan]

peize9 schreef op zaterdag 9 augustus 2025 @ 10:10:
Van wat ik lees is Wireguard het handigste. Gebruikte wij ook toen we van binnen naar buiten het schoolnetwerk moesten om ipv6 in het lab te krijgen

Ik heb wel even de vraag, ga je wonen in het buitenland of is het een vakantie ding? Wat is de usecase?

Heb je trouwens ook al nagedacht over ipv6? Als je dat op A kan krijgen kan je misschien nog kijken naar een soort tunnel die v4 traffic meeneemt over v6 of iets in die richting, maar daar heb ik me nog niet echt op ingelezen.

Een kennis heeft een huis in het buitenland met vast internet. De helft van het jaar staat het huis leeg, maar internet draait het hele jaar door. Ik mag er een device, bijvoorbeeld een raspberry pi plaatsen, maar aan de router komen mag niet.

Ik ga er niet wonen, soms wil ik het internet op gaan via dat specifiek land.

[Marc H]

Over hoeveel gebruikers hebben we het hier? Want als Pi hoor heb ik niet het idee dat het grote groepen gebruikers betreft.

Als het alleen voor jezelf is zou ik die hele VPS ertussen uit halen en een tool als Tailscale gebruiken.

[FrankHe]

c-nan schreef op zaterdag 9 augustus 2025 @ 10:14:
[...]

Een kennis heeft een huis in het buitenland met vast internet. De helft van het jaar staat het huis leeg, maar internet draait het hele jaar door. Ik mag er een device, bijvoorbeeld een raspberry pi plaatsen, maar aan de router komen mag niet.

Ik ga er niet wonen, soms wil ik het internet op gaan via dat specifiek land.

Heel vreemd dat de persoon wel toestaat dat je een Pi of iets dergelijks neerzet maar je niet toestaat om één NAT forward rule aan te maken. Persoonlijk vind ik dat inconsistent en niet heel erg logisch. Of je staat alles toe, device plus één NAT forward rule of je staat niets toe. Maar goed, zo denk ik daar over.

[c-nan]

Marc H schreef op zaterdag 9 augustus 2025 @ 10:14:
Over hoeveel gebruikers hebben we het hier? Want als Pi hoor heb ik niet het idee dat het grote groepen gebruikers betreft.

Als het alleen voor jezelf is zou ik die hele VPS ertussen uit halen en een tool als Tailscale gebruiken.

Gelijktijdig maximaal 3, maar 95% van de tijd 1 gebruiker.

[MartinMeijerink]

c-nan schreef op vrijdag 8 augustus 2025 @ 22:20:
Wat vinden jullie hiervan? Prima? Zou je het anders doen? Hoe zorg ik ervoor dat de SSH tunnel altijd up is, ook na een reboot van de VPS of van de rPi?

Prima oplossing, ik heb al jaren verschillende SSH-tunnels draaien, en mijn werkwijze is:
1. op de server in /etc/ssh/sshd_config heb ik dit staan om te voorkomen dat de verbinding wordt verbroken bij geen activiteit:

code:

ClientAliveInterval 120
ClientAliveCountMax 720

2. Op de client een executable script /pad/naar/sshtunnel.sh met daarin (vertaald naar jouw situatie):

code:

#!/bin/sh
ps -ef|grep \[s]sh|grep -q 1194:localhost:1194||ssh -N -R 1194:localhost:1194 [e-mail] &

3. En in de /etc/crontab:

code:

*/5 * * * * root /pad/naar/sshtunnel.sh

Hiermee wordt elke 5 minuten gecheckt of de tunnel nog aan staat, en zo niet, dan wordt deze gestart.

Dit alles bij elkaar zorgt voor een zeer stabiele SSH-tunnel, en mocht de verbinding ooit worden verbroken door een internetonderbreking of een reboot van client of server, dan is deze binnen 5 minuten weer up.

[laurens0619]

Je kunt ook tailscale gebruiken
Soort wireguard wat met holepunching door nat heen gaat

[FreakNL]

FrankHe schreef op zaterdag 9 augustus 2025 @ 10:19:
[...]

Heel vreemd dat de persoon wel toestaat dat je een Pi of iets dergelijks neerzet maar je niet toestaat om één NAT forward rule aan te maken. Persoonlijk vind ik dat inconsistent en niet heel erg logisch. Of je staat alles toe, device plus één NAT forward rule of je staat niets toe. Maar goed, zo denk ik daar over.

Persoon staat dat ook niet toe. Je leest niet goed.

[FrankHe]

FreakNL schreef op zaterdag 9 augustus 2025 @ 12:43:
[...]

Persoon staat dat ook niet toe. Je leest niet goed.

Het enige wat ik zeg is dat ik het inconsistent vind van die persoon. Als iemand veiligheid belangrijk vinden dan moeten ze helemaal niets toestaan. Sta je het wel toe om een apparaat in je netwerk te plaatsen sta het dan ook toe om een forward aan te maken. Het niet aanmaken van een forward is een soort schijnveiligheid. Maar goed, dat is mijn mening.

[FrankHe]

laurens0619 schreef op zaterdag 9 augustus 2025 @ 12:39:
Je kunt ook tailscale gebruiken
Soort wireguard wat met holepunching door nat heen gaat

In dit geval zul je inderdaad iets moeten hebben wat de holepunch doet en dat kan goed met Tailscale. WireGuard met een service van een derde partij die de verbindingen tussen de clients tot stand brengt. Dan heb je geen NAT forward nodig maar in plaats daarvan wordt er een stateful verbinding in de firewall gemaakt waarmee je feitelijk hetzelfde bereikt.

[c-nan]

Ik heb een test setup opgezet. OpenVPN icm reverse SSH tunnel, werkt als een zonnetje. Zodra je een UTP kabel in de rPi prikt waar DHCP aanwezig is werkt het automatisch.

rPi gereboot, internet afgesloten, UTP eruit erin, komt steeds weer automatisch up.

OpenVPN installatie en configuratie dmv https://www.pivpn.io/

Een systemd service zorgt ervoor dat de SSH tunnel altijd up is:

code:

[Unit]
Description=AutoSSH reverse tunnel to VPS
After=network.target

[Service]
User=pi
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -N -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" \
    -R 0.0.0.0:2222:localhost:22 \
    -R 0.0.0.0:1194:localhost:1194 \
    <user>@<vps>
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target