VPN server en client samen op RPi - routing probleem

[Flippi]

Op een Raspberry Pi heb ik PiVPN als server draaien waardoor ik mijn thuisnetwerk via een Wireguard VPN-tunnel extern kan benaderen (wg0).
Op dezelfde RPi heb ik ook een client van een commerciële VPN-service (Private Internet Access) geïnstalleerd, feilloos werkend via Wireguard (tun0).
Echter, van zodra de RPi verbinding maakt met de commerciële VPN-service werkt de externe verbinding met mijn thuisnetwerk niet meer.
Ik heb me al suf gezocht, maar krijg het niet werkend.
De vraag komt vaak terug op fora zoals Reddit, maar pasklare antwoorden zijn er niet, behalve dat het zou moeten kunnen door het aanpassen van IP routing tables, maar mijn kennis is ontoereikend om daarmee verder te kunnen.
Iemand die hier raad mee weet en mij verder kan helpen? Bij voorbaat dank.

Indien niet verbonden met Private Internet Access:

Code: Selecteer alles

@rpi4b:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
10.90.133.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

Indien verbonden met Private Internet Access:

Code: Selecteer alles

@rpi4b:~/Downloads $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.12.18.1      128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
10.0.0.243      10.12.18.1      255.255.255.255 UGH   0      0        0 tun0
10.12.18.0      0.0.0.0         255.255.255.0   U     0      0        0 tun0
10.90.133.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0
128.0.0.0       10.12.18.1      128.0.0.0       UG    0      0        0 tun0
181.214.206.141 192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

Netwerk.jpg

[dupondje]

De oorzaak is eenvoudig.

Je verbind met je mobiel bv naar het publiek IP adres van je internet verbinding.
Router doet NAT/portforwarding, wat je destination IP wijzigt. Vervolgens antwoord je rpi hierop, en stuurt hij dat terug naar het source IP. Echter gebruik makend van de route tabel, en dus gaat het verkeer naar buiten via de VPN.
Asymetrische routing dus.

Eenvoudigste oplossing is volgens mij een 2de IP op je rpi, je portforwarding daar naartoe en dan een ip rule dat verkeer naar dat ip een andere routetabel gebruikt met je router als def gateway.

[CCatalyst]

De reden is, zoals hierboven gezegd, de eerste route regel (0.0.0.0 10.12.18.1) die alle verkeer richting de PIA tunnel stuurt, ook verkeer dat PiVPN richting de VPN client stuurt. De VPN client zal dat verkeer om veiligheidsredenen droppen gezien hij verwacht dat het uw network is die antwoordt op het verzoek om de tunnel op te zetten, en niet het netwerk van PIA dat compleet onbekend is voor de client.

De theoretische oplossing is dat de VPN server van PiVPN bij het verzoek om een tunnel te openen een route moet configureren naar het IP adres van de VPN client, meer bepaald gateway 192.168.1.1 mask 255.255.255.255 metric 0. Het verkeer dat PiVPN richting de client stuurt zal dan niet via de PIA tunnel verlopen. Bij PiVPN met OpenVPN is het eenvoudig, je kan de --route optie gebruiken in de config van OpenVPN.

Echter, ik vrees dat je botst op een limitatie van Wireguard dewelke zo'n optie niet lijkt te hebben (ik kan verkeerd zijn). Wireguard is een wat "eenvoudigere" VPN-oplossing dan OpenVPN, het nadeel is dus ook minder opties.

Is PiVPN met OpenVPN een optie?

Mits het adres van de client altijd dezelfde is of in dezelfde mask zit, kan je een uitzondering hiervoor configureren in de ACL van de PIA configuratie, maar dat zal vermoedelijk wel niet het geval zijn.

Of de creatieve oplossing van dupondje hierboven (maar niet eenvoudig om dit juist te doen zonder ervaring inzake).

[brubbel]

"AllowedIPs" in de wireguard config dient daarvoor.
bijvoorbeeld: AllowedIPs = 10.13.13.0/24

https://www.procustodibus.com/blog/2021 ... alculator/

[Flippi]

Bedankt alvast voor jullie bereidwilligheid om dit probleem(pje) te helpen oplossen, maar ik vrees dat deze materie mijn petje te boven gaat.
Ik heb alvast geprobeerd om in de PiVPN client op mijn smartphone de regel AllowedIPs = 10.90.133.0/24 aan de config toe te voegen (@brubbel bedoelde je het zo?), maar dan kon ik niet meer op mijn thuisnetwerk.

Het lijkt me inderdaad de moeite van het proberen waard om het voorstel van @CCatalyst eens te proberen, dat moet me wel lukken met één van de talrijke tutorials die hierover te vinden zijn.

Ik breng nog wel verslag uit hoe het verlopen is.

[CCatalyst]

"AllowedIPs" in de wireguard config dient daarvoor.

AllowedIPs is idd die ACL die ik vermeld heb. Er wordt een route gezet om alles naar de wireguard interface te routeren, en dan beslist wireguard ahv die ACL wat wel/niet door de tunnel gaat.

Het probleem is echter dat in het geval van PiVPN het IP van de VPN client niet statisch is en wellicht ook niet in 1 subnet zal blijven. Dat maakt het werken met ACL moeilijk, tenzij je de ACL on the fly kan aanpassen via command line oid (maar dat kan volgens mij niet in wireguard).

Zoals ik zei: als het IP van de PiVPN client voorspelbaar is, ttz het is statisch of blijft minstens in dezelfde mask (bv altijd in het netwerk van Proximus), kan je dit wel doen met AllowedIPs, maar ik vermoed dat dit niet het geval is.

OpenVPN heeft als voordeel dat je de server kan configureren dat hij een route zet naar de client bij het opbouwen van de tunnel (en eenmaal de tunnel afgebroken wordt verwijdert hij die route weer). Zolang de metric van die route ook op 0 staat zou die route moeten winnen over de "0.0.0.0" route die wireguard instelt gezien de hogere specifiteit. Het verkeer naar de PiVPN client gaat bijgevolg dus niet langs de PIA wireguard interface maar direct naar de upstream router, wat het probleem in kwestie zou moeten oplossen.

[Flippi]

Ik ben herbegonnen met een nieuwe installatie van het OS op mijn Pi en heb er opnieuw PiVPN - deze keer met OVPN - op gezet.
Ik slaag er opnieuw in om een tunnel van buitenaf op te zetten naar mijn netwerk.
Eens ik mijn Pi verbind met de externe VPN-service (PIA) wordt mijn netwerk zoals verwacht onbereikbaar van buitenaf.

Vervolgens heb ik de volgende regel toegevoegd aan /etc/openvpn/server.conf:
route 10.90.133.0 255.255.255.255 192.168.1.1 0
Bestand opgeslagen en mijn Pi herstart, maar jammer genoeg enkel verbinding van buitenaf met mijn thuisnetwerk wanneer ik NIET met PIA verbonden ben.

Als die toegevoegde regel effectief zou uitgevoerd worden, zou ik dat dan ook niet moeten zien in mijn routing table? Die wijzigt nl. niet na toevoeging van de extra regel.

Edit: ik zie nu dat ik de server.conf van mijn VPN-server heb bewerkt terwijl dat waarschijnlijk de client-config van PIA had moeten zijn. Ik probeer hier morgen een vervolg aan te breien.

[dupondje]

Je gaat dit enkel kunnen oplossen met ip rules volgens mij. En niet door gebruik te maken van OpenVPN.

Het probleem is dat je verbind met je public IP adres. Verkeer komt toe op je PiVPN, maar als de PIA VPN aanstaat, dan wordt response gerouteerd naar PIA.
Er komt dus ook nooit geen respons toe op de client, en er zal zelf geen VPN tunnel aangemaakt worden, dus ook nooit geen extra route ofzo door OpenVPN.

Enige oplossing zullen IP rules zijn...

[Flippi]

Eventjes verder kunnen testen.
De regel route 10.90.133.0 255.255.255.255 192.168.1.1 0 toegevoegd aan het client-config-bestand (.ovpn) van de PIA VPN service, echter zonder succes.
De tunnel van buitenaf naar mijn thuisnetwerk wordt verbroken of kan niet worden aangemaakt indien er een verbinding is met een PIA-server.

Niet dat dit nu zo belangrijk is, maar ik heb me hier in vastgebeten met de zeer beperkte kennis die ik heb en ik kan het niet loslaten.
Ik probeer eens de route van de ip-rules, maar moet hier ook van nul beginnen.

Code: Selecteer alles

~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.20.112.1     128.0.0.0       UG    0      0        0 tun1
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
10.20.112.0     0.0.0.0         255.255.255.0   U     0      0        0 tun1
10.90.133.0     192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
10.90.133.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0
128.0.0.0       10.20.112.1     128.0.0.0       UG    0      0        0 tun1
191.101.157.80  192.168.1.1     255.255.255.255 UGH   0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

[CCatalyst]

Enige oplossing zullen IP rules zijn...

Vraag die nog niet beantwoord is: hoe doe je dit als je met dyamische IP's te doen hebt? Het IP alwaar van buitenaf verbonden wordt is dynamisch.

De tunnel van buitenaf naar mijn thuisnetwerk wordt verbroken of kan niet worden aangemaakt indien er een verbinding is met een PIA-server.

Bij het debuggen met tunnels is het belangrijk van het probleem te pinpointen ahv traceroutes en packet dumps zodat je weet hoe de pakketten in de realiteit gerouteerd worden. Doe je een traceroute (langs beide kanten) om te verifieren welke route de pakketten nemen, kwestie van te verifieren dat de routing effectief correct verloopt?

Bv in de tabel van je laatste post: elk pakket zal door tun1 gaan (is dat wireguard of OpenVPN?), tenzij degene voor 10.90.133.0/24 (tun0) en 191.101.157.80/32 en uiteraard 192.168.1.0/24 (eth0).

[dupondje]

Vraag die nog niet beantwoord is: hoe doe je dit als je met dyamische IP's te doen hebt? Het IP alwaar van buitenaf verbonden wordt is dynamisch.

Alias interface toevoegen met een andere intern IP
Portforward op je router naar dat IP voor de VPN
En dan:

Code: Selecteer alles

echo 200 vpn >> /etc/iproute2/rt_tables
ip rule add from <interface_IP> table vpn
ip route add default via <gateway_IP> dev <interface> table vpn

En dat zou moeten werken

[Flippi]

A.d.h.v. losse flarden informatie hier en daar op het Internet en de hulp van @dupondje en @CCatalyst hier op het forum ben ik er dan uiteindelijk toch in geslaagd om te bereiken wat ik wou. T.t.z. met PiVPN een inkomende tunnel (tun0) naar mijn thuisnetwerk creëren terwijl mijn Pi via een uitgaande tunnel (tun1) met een commerciële VPN-service verbonden is.
Bij een standaard installatie van PiVPN wordt de verbinding via de inkomende tunnel verbroken zodra de Pi verbinding met een commerciële VPN maakt.

Zoals eerder aangegeven door CCatalyst is OpenVPN the way to go en op comparitech wordt - om conflicten bij deze specifieke setup te vermijden - aangeraden om gebruik te maken van het TCP-protocol en een poortnummer dat *niet* gelijk is aan het standaard poortnummer 443 voor TCP.

Een Dynamic DNS van bijv. No-IP zorgt ervoor dat steeds kan verbonden worden met het thuisnetwerk.
Op de router dient een port forward te worden ingesteld.

Pasted image 20240109234648.png

Aan het configuratiebestand van de commerciële VPN-service (gedownload als *.ovpn en hernoemd naar *.conf in de folder /etc/openvpn/) werd onderstaande regel toegevoegd om het lan-verkeer niet door de uitgaande tunnel te sturen:

Code: Selecteer alles

route 192.168.1.0 255.255.255.0 192.168.1.1

De routing table werd aangepast door de 2 onderstaande regels aan het bestand /lib/dhcpcd/dhcpcd-hooks/40-routes toe te voegen:

Code: Selecteer alles

ip rule add from 192.168.1.97 lookup 101
ip route add default via 192.168.1.1 table 101

Met de aanpassingen hierboven is het nu mogelijk om bijv. met mijn smartphone te connecteren met mijn thuisnetwerk terwijl mijn Pi verbonden is met een commerciële VPN-service.
Echter is het nog niet mogelijk om mijn smartphone het Internet te laten op gaan via de commerciële VPN. Typ daarvoor in de CLI de volgende regels:

Code: Selecteer alles

sudo iptables -t nat -A POSTROUTING -o tun1 -j MASQUERADE
sudo sh -c "iptables-save > /etc/iptables/rules.v4"

Om na een reboot ook nog alles werkend te houden werd onderstaande regel toegevoegd aan /etc/rc.local:

Code: Selecteer alles

iptables-restore < /etc/iptables/rules.v4

Een nieuw probleem is nu dat mijn Pi niet meer bereikbaar is op het adres 192.168.1.97.
Dit heb ik kunnen oplossen door een 2de IP aan het mac-adres van mij Pi toe te wijzen door onderstaande vier regels aan het bestand /etc/network/interfaces toe te voegen:

Code: Selecteer alles

iface eth0:0 inet static
address 192.168.1.4
netmask 255.255.255.0
auto eth0:0

Om conflicten te vermijden kies je best voor een IP-adres dat buiten de IP-range van de DHCP-server valt (range zelf in te stellen op de router).

Getest op een Raspberry Pi 4B met 4GB geheugen.
Raspberry Pi OS Debian versie 11 Bullseye.

Zo, misschien heeft iemand anders er ook iets aan. Bedankt voor de hulp.