OpenVPN met local en remote hetzelfde subnet

[Jurgle]

Waerde GOTters,

Thuis heb ik een OpenVPN server opgezet. Werkt als een tierelier, behalve: als het subnet van het LAN waar ik op dat moment ben ook mijn subnet thuis omvat. Op verschillende fora vind ik zaken als 'push route...' etc, maar het sluit niet helemaal aan op mijn situatie en zie ik door mijn beperkte kennis van netwerken door de bomen het bos niet meer.

De situatie:
Thuis heb ik een 192.168.1.0/24 subnet
Met het VPN heb ik een 10.8.0.0/(minstens 16 maar is denk ik niet relevant) subnet
Het netwerk waar ik nu ben, laten we het A noemen, heeft een 192.168.0.0/16 subnet

Het gaat er specifiek om, dat ik als ik verbonden ben met mijn VPN, ik 192.168.1.80 kan bereiken die thuis staat.

Door wat ik gelezen had, dacht ik dat een regel:

code:

push route 192.168.1.80 255.255.255.255

in /etc/openvpn/server/server.conf het zou oplossen, omdat ik dacht dat ik daarmee alleen voor dat IP mijn thuisnetwerk over het VPN zou bereiken en voor de andere IPs binnen 192.168.0.0/16 de machines in netwerk A.

Dit lijkt echter niet zo te zijn (of een /etc/init.d/openvpn restart laadt /etc/openvpn/server/server.conf niet opnieuw (toen ik dat deed bleef mijn verbinding immers ook intact).

Ook hier op de gathering is er (onlangs nog) over dit onderwerp een draadje gestart die ongeveer wilde doen wat ik wil (maar dan voor het hele subnet):

Chris-1992 schreef op zondag 19 februari 2023 @ 15:33:
Goedemiddag,

Via pfSense (Netgate) hebben we een OpenVPN server opstaan.
Client - Server opstelling.

Probleem is dat op kantoor 192.168.0.0/24 subnet is.
De meeste thuisnetwerken bij ons zijn ook 192.168.0.0/24.
Hoe kan ik ervoor zorgen dat al het trafiek over deze VPN gaat?
Liefst een parameter in de config zodat we deze automatisch kunnen meesturen bij de installatie.


Home: 192.168.0.0/24
VPN: 192.168.14.0/24
Office: 192.168.0.0/24

redirect-gateway def1 werkt niet.

Alvast bedankt!

maar zonder oplossing, waarbij cttl01 terecht opmerkt:

cctl01 schreef op zondag 19 februari 2023 @ 15:42:
--- Mag gesloten worden

Kijk, hier hebben mensen met het zelfde probleem in de toekomst wat aan.

Wat is jullie mening/advies over dit vraagstuk waar ik ongetwijfeld niet als enige mee zit?

[Jurgle]

Heb intussen een tijdelijke oplossing gevonden, maar ben nog steeds benieuwd naar hoe ik de OpenVPN server deze route-regel kan laten pushen naar een client als onderdeel van de VPN sessie zelf (die dan ook weer netjes wordt opgeruimd als de VPN verbinding weg is.

Ik gebruik een mac en met IFCONFIG vind ik mijn virtual VPN adapter:

code:

utun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
    inet 10.8.0.2 --> 10.8.0.2 netmask 0xffffff00

Vervolgens kan ik op mijn mac de volgende route toevoegen:

code:

sudo route add 192.168.1.80 10.8.0.2

dit zorgt ervoor dat een verbinding met 192.168.1.80 over het VPN geroute wordt en dus bij mij thuis uitkomt.

Nu moet ik wel elke keer als ik de VPN uitzet deze route weer weggooien natuurlijk. Daarom maak ik het nog graag onderdeel van de VPN-sessie-configuratie (in de server configuratie of in de ovpn file).

[Freeaqingme]

Oke, dus je hebt 2 netwerken: Netwerk A waar je vpn-server zich bevindt, en netwerk B waar je vpn client zich bevindt.

De makkelijkste oplossing is om op netwerk A een range uit te kiezen die niet iedereen en z'n moeder gebruikt. Dan nog heb je natuurlijk kans op een collission, maar die is dan wel meteen een stuk kleiner.

Ik begrijp dat het je eigenlijk maar om 1 specifiek ip-adres gaat, namelijk 192.168.1.80/32 ? Dan zou die 'push route' directive inderdaad moeten werken. Daarvoor moet je wel de server herstarten nadat je 'm daar hebt toegeveogd, en daarna ook de client moeten herstarten (hij krijgt alleen de routes gepushed bij het opzetten van de verbinding).

Als het dan nog niet werkt wordt het tijd om te gaan debuggen. Wellicht kan je daarvoor je client config delen, en ook de logs van je client?

[Chris-1992]

@Jurgle
Ik ben nog altijd naar een oplossing aan het zoeken hoor
Zoals je al zei een static route aanmaken, dat is mijn oplossing op het moment.

[HMaster_II]

Wij draaien bij onze vestigingen een subnet wat totaal buiten de standaarden zitten. De OpenVPN oplossing draait op een NethServer firewall erbij. Het subnet wat bij 1 van de 3 VPN's draait is bijvoorbeeld 192.168.102.x en die zit ver genoeg van de standaard 192.168.(0/1).x of 192.168.178.x subnetten van de "algemene" providers.
Mogelijk dat je hier naar kan kijken. Niet de basic subnetten via dhcp in OpenVPN pushen, maar iets wat er ver buiten ligt.

[CAPSLOCK2000]

Jurgle schreef op woensdag 29 maart 2023 @ 14:26:

Wat is jullie mening/advies over dit vraagstuk waar ik ongetwijfeld niet als enige mee zit?

Heb je IPv6 overwogen?

De kern van het probleem is immers dat we ranges dubbel gebruiken omdat er te weinig adresruimte is om iedereen z'n eigen unieke stukje te geven.

Nu ondersteunt niet ieder apparaat IPv6 maar als je toch je eigen VPN opzet heb je daar niks mee te maken.
Als je nog nooit iets met IPv6 gedaan hebt is dat wel een wat grotere stap omdat dan wat je nu probeert (extra routes) omdat je eerst IPv6 moet configureren op je netwerk maar uiteindelijk is het wel de betere oplossing.

[Frogmen]

Thuis dus een ander netwerk dan 192.168.1.0 of 2.0 instellen dat zijn zulke standaard ranges dat je er altijd met VPN problemen mee hebt. Gebruik 192.168.114.0 bijvoorbeeld dan is die kans vaal kleiner.