In het verleden wel eens van PPTP VPN gebruik gemaakt maar toch maar van afgestapt en nu eindelijk een OpenVPN config opgezet met een Debian VM.
De verbinding werkt maar nu wil ik ook devices op mijn LAN kunnen aanspreken maar dat lukt niet meteen.
In de server config heb ik volgende regel toegevoegd
Client vpn of site to site?
Bij dat laatste moet je opletten dat beide kanten een route naar mekaar hebben.
Welk toestel handelt de vpn af? De router?
Indien niet de router: heeft de router een route naar de vpn unit voor die range?
Want je toestellen gaan bij gebrek aan een route bij hen allemaal hun default gateway gebruiken, je router, en die moet uiteraard de weg kennen naar de vpn tunnel.
Hoi ITnetadmin
Client VPN, W8.1 naar Debian VM achter BBox3. (enkel portfowarding ingesteld op modem)
Heb net in /etc/openvpn/client/ een client(met en zonder .conf) file aangemaakt met "iroute 192.168.1.0 255.255.255.0" (subnet van mijn W8.1 client)
Ook in de server.conf heb ik "route 192.168.1.0 255.255.255.0" toegevoegd.
Krijgt de client een ip adres uit je interne range?
Indien niet, moet je echt wel op de router (enfin, technisch gezien de default gateway van je netwerk) een static route toevoegen naar je server toe.
Anders gaan de interne devices die niet vinden.
IP routing is nl geen twoway street, maar twee oneway connecties; het is niet omdat het pakketje van A naar B geraakt, dat het antwoord ook de weg van B naar A vindt.
Iirc, krijg je bij een site-to-site vpn altijd een aparte range aan beide kanten.
In dat geval moet je idd aan beide kanten je static route just definieren indien het toestel dat de vpn opbouwt niet de router (aka default gateway) is van dat netwerk.
Bij een client VPN krijgt de client meestal een ip in de range van het server netwerk, dat dan getunneld wordt.
Misschien dat openvpn dat anders doet voor clients, ik gebruik eigenlijk enkel openvpn voor site to site setups.
Opgepast wel: bij openvpn noemen alle setups "client-server", ook de site to site setups.
Dat geeft uiteraard superveel verwarring.
Voor zo'n zaken kan een packet capture langs beide kanten meestal snel aantonen waar het probleem zich situeert.
Start een continue ping van de client naar een toestel dat actief is (en antwoordt op pings!) op het LAN en kijk dan met tcpdump/Wireshark tot waar de pings (en evt de antwoorden) komen. Waar ze gedropt worden zit je probleem.
Routing, NAT, filtering, ... kunnen allemaal het probleem zijn. Dit is typische troubleshooting voor VPN deployments, niet enkel OpenVPN btw.
Zoals ik al zei, door de pakketten eens te volgen zou als snel duidelijk moeten worden waar het probleem zich stelt. Daarmee is het nog niet opgelost, maar je moet eerst weten wat het probleem is, anders kan je lang zoeken.
Okee, openvpn gebruikt dus aparte netwerken.
Dan is het eigenlijk niet moeilijk.
Op *beide* netwerken moeten de toestellen het andere netwerk weten te vinden.
Als in beide gevallen de gewone netwerk router de tunnel opzet, hoef je niks extra te doen.
Gebruik je een apart device, dan moet je extra config gaan uitvoeren.
Je apparaten gaan nl alle pakketjes die niet voor hun eigen netwerk bestemd zijn, afleveren adhv hun routing table.
Voor de meeste devices is die table simpel, gewoon hun default gateway, aka de router van het netwerk.
Die router moet dan een static route krijgen.
Maw, je voert een static route toe in de router, naar het netwerk van de andere kant van de vpn tunnel, en kiest als destination het ip van het toestel dat de vpn opzet.
Nogmaals: je moet dit langs beide kanten doen.
Een pakketje dat een round trip van A naar B wilt doen doet dit als volgt:
Pakjetje vertrekt bij toestel A; dit toestel stuurt het pakketje naar zijn default gateway, de router.
De router zoekt de locatie op van de bestemmeling en vindt die in zijn static routes, hij stuurt het vervolgens naar het vpn device.
De vpn stuurt het pakketje door de tunnel.
Daar aangekomen stuurt de vpn het naar bestemmeling B.
B stuurt een antwoord.
Hij stuurt dit naar zijn default gateway, de router.
Die zoekt het destination network op in zijn routing table, en stuurt het door naar het vpn device.
Die stuurt het door de tunnel en aan de andere kant naar A.
Die static routes zijn dus superbelangrijk in volgende situaties:
1) De router van het netwerk is niet het device dat de vpn opzet
2) De zender van het pakket bouwt zelf de vpn tunnel niet op
