OpenVPN routing

[SF-Jeroen]

Ik heb vandaag OpenVPN geïnstalleerd op een debian 6 server. Daarna netjes de keys geëxporteerd naar de cliënt (op dit moment OpenVPN GUI op Windows Vista). Ik kan na het verbinding maken gewoon pingen naar de tunnel ip's op zowel de client als de server. Ook kan ik naar de andere 2 interfaces op de server pingen (eth0 met het externe IP, en eth1 met een virtueel netwerk (192.168.1.x).

Helaas kan ik geen andere devices op het virtuele netwerk of internet bereiken.

Globale opzet:

Client (vpn = 172.0.0.6) - IP wisselt per cliënt, hangt achter NAT router. Heeft 2 interfaces.
Server (vpn = 172.0.0.1) - Heeft 3 interfaces (eth0 = extern, eth1 = intern, tun0 = vpn)

Routing tabel op de server:



Destination Gateway Genmask Flags Metric Ref Use Iface
172.0.0.2 * 255.255.255.255 UH 0 0 0 tun0
172.0.0.0 172.0.0.2 255.255.255.0 UG 0 0 0 tun0
***.***.196.0 * 255.255.255.0 U 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth1
default gw-v123.*****.n 0.0.0.0 UG 0 0 0 eth0


Ik snap hier al niet precies waar hij de gateway 172.0.0.2 vandaan haalt, dit staat namelijk nergens in de OpenVPN instellingen.

Een route naar 192.168.1.0/24 via de VPN toevoegen op de cliënt heb ik al geprobeerd, maar dat lost het niet op.

Het doel is dus dat ik vanaf de client via de VPN alle devices in het 192.168.1.0/24 netwerk kan pingen alsmede via de server het internet op kan.

[hrodenburg]

Forward je openvpn server uberhaubt wel packets? Geeft

cat /proc/sys/net/ipv4/ip_forward wel "1" terug?

[SF-Jeroen]

Ja, die geeft gewoon 1 terug.

[hrodenburg]

Openvpn gebruikt standaard volgens mij een ip in de range die je opgegeven hebt voor clients. Dat verklaard je 172.0.0.2. Verder neem ik aan dat je routes ook kloppen? Dus ook een route op je "LAN" netwerk naar je openvpn clients? Ook geen firewall op de openvpn server in de weg?

[SF-Jeroen]

De range klopt, alleen zou ik verwachten dat de route naar 172.0.0.0/24 niet via 172.0.0.2 zou lopen, want dit IP bestaat gewoon niet. De server/cliënt hebben beiden geen firewall aanstaan. Op de cliënt heb ik een route naar 192.168.1.0/24 lopen via 172.0.0.1.

[SF-Jeroen]

Ik heb voor de zekerheid de routing tabellen door RIP laten vullen. Daarnaast gezorgd dat de cliënt nu een statisch ip van 172.0.0.2 krijgt. Het probleem is niet veranderd.

[SF-Jeroen]

Ik heb het nu soort van opgelost, door een statische route aan te maken vanaf een van de servers in de 192-range naar 172.0.0.2. Dit is natuurlijk niet helemaal de bedoeling. Ik denk dat dit iets te maken heeft met de IP-masquerading. Op de server staat nu ingesteld "MASQUERADE all -- 172.0.0.2 anywhere". Zouden daar nog regels bij moeten, en zo ja welke?

[SF-Jeroen]

Topic mag dicht. Oplossing was vrij simpel achteraf.

Op de server ingesteld; iptables -t nat -A POSTROUTING -s 172.0.0.0/24 -j MASQUERADE
Op de lokale server ingesteld; iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE

En dan hoeft de cliënt verder niets te installeren, omdat de routering via de lokale server gaat.