Morgen Leute,

ich häng mal wieder irgendwo, die "Lösung" habe ich zwar mehr oder weniger aber wie ich das umsetze weiß ich nicht

Folgendes Problem:

Ich erreiche keine anderen IP-Adressen hinter meinem VPN-Server. Der VPN-Server selbst lässt sich pingen und die notwendige Route ist sowohl

in der Serverkonfiguration eingetragen als auch beim Verbinden dem Client übermittelt worden. (route print)

Nach etwas google, stoß ich auf folgendes heise.de Zitat:

Das funktioniert ohne weitere Tricks allerdings nur unter zwei Voraussetzungen: Erstens darf auf der Client-Seite nicht derselbe Adressbereich zum Einsatz kommen. Und zweitens muss sichergestellt sein, dass die Pakete aus dem LAN den richtigen Weg zum VPN-Client finden. Das passiert automatisch, wenn der OpenVPN-Server auch das Standard-Gateway für die Rechner im Server-LAN ist. Ansonsten muss entweder das Gateway eine passende Route haben, die Pakete für 10.8.0.0/24[14] an den OpenVPN-Server weiterleitet, oder diese Route muss auf allen Clients eingetragen werden.

Also erstens ist erfüllt, nur zweitens, mein VPN-Server ist nämlich nicht mein Gateway den ich zum Internet brauche, daher hat er auch selbst einen anderen eingetragen. Den Standardgateway möchte ich also nicht ändern.

So der nächste Satz erklärt eigentlich alles, bloß wie setze ich das um?!? Wie trage ich das ein und was genuau?

Ich komme nicht drauf...

Vielleicht stand jemand schon vor dem selben Problem

Danke

gruß Jens

Vielleicht liegt es daran, das Montag ist, aber kann es sein, das du weder Client- noch Server-OS angegeben hast ? Wär schon hilfreich...

Naja, falls dein Server Linux ist solltest du mal schauen ob IP-Forwarding im Kernel aktiviert ist, das ist nämlich ne schöne Stolperfalle

Ich dachte das ist unrelevant für eine Routing Befehl.

Beide OpenVPN Versionen auf 2.0.9

IP-Forwarding ist aktiviert.

Die Route wird auch mitübergeben.

Ich schätze ich muss irgendeinen route add befehl bilden, doch alle Versuche bis jetzt schlugen fehl oder passten vom Syntax nicht

Interresant ist aber auch ein tracert vom client:

Ich möchte hinter meinem VPN-Server (Hat IP 192.168.0.2) den Server 192.168.0.1 tracen.

Laut tracert nimmt er als ersten HOP, 10.8.0.1 weiter gehts nicht. Aber immerhin nimmt er schonmal den richtigen Weg.

Ich hatte an sowas in der Richtung gedacht am Server gedacht:

route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.8.0.1 dev tun0

Funktioniert aber nicht Mein tun0 Device sagt über tcpdump folgendes:

11:39:28.167742 IP 10.8.0.6 > 192.168.0.2: ICMP echo request, id 1024, seq 22016, length 40

11:39:28.167745 IP 192.168.0.2 > 10.8.0.6: ICMP echo reply, id 1024, seq 22016, length 40

11:39:29.168317 IP 10.8.0.6 > 192.168.0.2: ICMP echo request, id 1024, seq 22272, length 40

11:39:29.168340 IP 192.168.0.2 > 10.8.0.6: ICMP echo reply, id 1024, seq 22272, length 40

11:39:31.196506 IP 10.8.0.6 > 192.168.0.1: ICMP echo request, id 1024, seq 22528, length 40

11:40:01.391333 IP 10.8.0.6 > 192.168.0.1: ICMP echo request, id 1024, seq 22784, length 40

11:40:06.812339 IP 10.8.0.6 > 192.168.0.1: ICMP echo request, id 1024, seq 23040, length 40

Es wird anscheinend schon richtig dahin geroutet nur kommt nix zurück

Du musst auf dem Router eine Route für das VPN Clientnetz einrichten, mit dem Server als Gateway. Der Server selber kennt das Clientnetz, aber anderen Clients nicht. Sie werfen die Pakete dann auf die Defaultroute, aber der Router kann damit auch nix anfangen. Wenn er aber weiß, über welches Gateway er das VPN Clientnetz erreichen kann, dann ist wieder alles okay.

Ja ich war schon ein bisschen blöde...

Als ich als Gateway bei meinem Switch z.b. den VPN-Gateway als Gateway eintrug war alles nullproblemo.