OpenVPN und Routing

Kontrolliere nochmal die Werte auf dem OSX Server mit:
sysctl net.inet.ip
ob forwarding auch wirklich enabled ist. Verschiedene Dinge lassen sich auf
den Macs nicht oder nur schlecht von der command line einstellen.

Diese beiden Werte sollten so aussehen:
net.inet.ip.forwarding: 1
net.inet.ip.fw.enable: 1

Auch die von Dir beschriebene Prozedur im Server Admin solltest Du durchfuehren
und danach die Werte nochmal vergleichen.
 
Ahoi,

so nun habe ich mich nochmal schlau gemacht mit dem ip-forwarding und der Firewall
unter OS X und ich denke das dies nun so laeuft das alles ordnungsgemaess weiter-
gleitet wird. Die Firewall laesst alles brav durch any to any (der Server is ueber
eine Hadwarefirewall abgesichert).

Nun hab ich folgendes Probiert:

Code: 
VPN Client 10.0.20.101 tracert -> 10.0.2.11 (Linux Server)

Tracing route to 10.0.2.11 over a maximum of 30 hops

  1    88 ms    86 ms    80 ms  10.0.20.254
  2    73 ms    71 ms    54 ms  10.0.2.11

Trace complete.

Code: 
VPN Client 10.0.20.101 tracert -> 10.0.2.254 (Router)

Tracing route to 10.0.2.254 over a maximum of 30 hops

  1   221 ms   107 ms   119 ms  10.0.20.254
  2    93 ms   101 ms   102 ms  10.0.2.254

Trace complete.

Code: 
VPN Client 10.0.20.101 tracert -> 10.0.1.111 (Notebook)

Tracing route to 10.0.1.111 over a maximum of 30 hops

  1    65 ms    71 ms    72 ms  10.0.20.254
  2    66 ms    67 ms    71 ms  10.0.1.254
  3  10.0.1.254  reports: Destination net unreachable.

Trace complete.

Also der Router gibt mir wenn ich ins 10.0.1.0 Netz will eine Meldung
"Destination net unreachable."

Liegt das denn dann an dem Router? Verweigert er dem 10.0.20.0 Netz die
"Durchfahrt" oder liegt es an dem Routing auf dem VPN Server 10.0.2.10?

salut till
 
TCM schrieb:
also irgendwas passt da hinten und vorne nicht. der server meint, er und der peer haetten .1 und .2. wo kommt denn dann auf dem client .5 und .6 her?
Zum Vergrößern anklicken....

Das ist so korrekt. OpenVPN betreibt bei diesem neuen Client-Server Mode einen virtuellen Router intern. Dazu verwendet er das erste /30er Netz aus der angegeben Range. Somit hat der bei 10.0.20.0 das 10.0.20.0/30: .0 fuers Netz, 1 fuer das tun auf dem OSX Server, .2 fuer das mit dem Host verbundene virtuelle Interface im Router, .3 der Broadcast. Naechstes freies Netz dann .4/30.

Fuer den eigentlichen Client-Server Tunnel wird dann auf der Seite des Servers nicht mehr direkt das tun interface verwendet, sondern dieser virtuelle Router (jetzt sollte auch der Unterschied von route und iroute klar sein - iroute sind die Routingeintraege fuer diesen internen (virtuellen) Router). D.h. es wird als naechstes Netz dann 10.0.20.4/30 vergeben: .4 fuers Netz, .5 und .6 fuer die beiden peer Interfaces.

Man kann openvpn aber wohl auch auf echtes p-t-p umstellen. Dann spart man sich 2 Adressen pro Client fuer Netz und Broadcast. Windows kann das halt nicht (deshalb dieser erstmal etwas verworren anmutende Tanz mit den 30er Netzen).
 
Tillman schrieb:
Hab jetzt mal das ganze was anders Probiert:
Zum Vergrößern anklicken....

Du kannst zwar die IP Adressen auch manuell vergeben, aber das ist voellig unnoetig. So wie OpenVPN es vergeben hat, ist das voellig korrekt. Ich entdecke auch erstmal keine Fehler (habs aber ehrlich gesagt grossteils nur ueberflogen). Du solltest mit der zuerst genannten Konfiguration weitersuchen. Man kann zwar auch manuell Adressen vergeben, aber damit gibt man voellig unnoetig ein Feature auf und ich da bei openvpn Anweisungen teilweise Macros sind, ueberblicke ich jetzt auch nicht auf die Schnelle, ob es da zu Kollisionen kommt, so wie Du das gemacht hast. Dadurch wirds also nur unuebersichtlicher.

Lass uns mal bitte schauen, bis wohin Deine Pings kommen. Traceroute & Co. sind dazu unhandlich, weil Du da nicht immer siehst, ob der Request oder das Replay nicht durchgestellt wird und die ICMP Error Antworten da manchmal etwas verwirrend sind.

Mach mal bitte folgendes und poste das Ergebnis:

auf dem externen VPN Client einen Ping auf eine Adresse in dem nicht zu erreichenden Netz.

Auf dem LAN Interface des OSX Servers ein tcpdump (gibts sowas auf OSX?) proto ICMP.

Folgende Fallunterscheidung:
a) Kein Echo Request zu sehen: OpenVPN total vermurkst oder Problem auf dem OSX Server
b) kein Echo Reply zu sehen: Der Request schafft es entweder nicht bis zum Ziel oder die Antwort schafft es nicht bis zum OSX Server zurueck - > Problem liegt beim Router oder beim Ziel.
c) sowohl Request als auch Reply sind zu sehen: OpenVPN vermurkst oder Problem auf dem OSX Server.

Falls oben Fall c eintritt:

Gleiches nochmal wiederholen. Diesmal machst Du den tcpdump auf dem LAN Interface des angepingten Zielrechners. Dort wuerde mich auch nochmal obige Unterscheidung interessieren.

Falls dort gar nichts ankommt: Routerpoblem.
Falls dort trotz Request kein Reply rausgeht: Routingproblem oder Firewall auf Client.
Falls dort sowohl Request ankommt als auch Reply rausgeht: Routerproblem.

Bei Routerproblem waers nochmal interessant, wie der trace auf dem Router aussieht. Eigentlich haette man den zuerst getestet, aber ich weiss nicht, ob Du da dran kommst.

Obiges Verfahren ist eigentlich immer die beste Methode, um Routingproblemen auf die Spur zu kommen. Setzt natuerlich voraus, dass man die Kontrolle ueber alle Hops hat. Ich schicke ein Paket durch und schaue dann Hop fuer Hop nach, ob es noch durchgeht. Bis ich beim ziel bin. Danach dann den Rueckweg. Irgendwo muss es mal haengenbleiben. Und da setzt man dann mit der Fehlersuche an.
 
Hallo,

also mit dem tcpdump habe ich mich bisher noch nicht weiter mit beschaeftigt daher
kann ich dir leider nichts dazu geben, das Kommando gibt es aber unter OS X.

Folgendes habe ich probiert und wuerde fast behaupten dass das Problem wohl
in Richtung routing auf dem Router geht.

Also ein Ping aus dem 10.0.1.0-Netz von einem Client (10.0.1.111) in Richtung
VPN Client (10.0.20.101) bringt folgendes Ergebniss:

Code: 
iBook:~ admin$ ping 10.0.20.101
PING 10.0.20.101 (10.0.20.101): 56 data bytes
36 bytes from router.xxx.xxx.de (10.0.2.254): Redirect Host(New addr: 10.0.2.10)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 0054 f6cd   0 0000  40  01 5a08 10.0.1.111  10.0.20.101

##############

10.0.1.254/10.0.2.254 = Router der die beiden Netze 10.0.1.0 und 10.0.2.0 miteinander verbindet.

10.0.2.10 = OS X Server auf dem der OpenVPN Server Laeuft.

10.0.20.101 = VPN Client.

Ein Ping vom VPN Client (10.0.20.101) Richtung des Clients (10.0.1.111)
bringt folgendes:

Code: 
Pinging 10.0.1.111 with 32 bytes of data:

Reply from 10.0.1.254: Destination net unreachable.
Reply from 10.0.1.254: Destination net unreachable.
Reply from 10.0.1.254: Destination net unreachable.
Reply from 10.0.1.254: Destination net unreachable.

Ping statistics for 10.0.1.111:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

##############

10.0.1.254/10.0.2.254 = Router der die beiden Netze 10.0.1.0 und 10.0.2.0 miteinander verbindet.

Bin ich damit recht in der Annahme das wenn der Router antwortet er mit den
Daten nichts anfange kann weil ihm eine Route fehlt? Oder kann das Problem
dennoch auf dem Server liegen?

Habe auf dem Lancom Router ein trace + ip-router ausgefuehrt und dabei wurde
folgendes hervorgebracht:

Code: 
[IP-Router] 2006/09/06 11:56:07,190
IP-Router Rx (LAN):
DstIP: 10.0.1.111, SrcIP: 10.0.20.101  TOS: ----
Prot.: ICMP (1)  echo request, id: 0x0400, seq: 0x9a01
Time exceeded => Discard

[IP-Router] 2006/09/06 11:56:07,310
IP-Router Rx (LAN):
DstIP: 10.0.1.111, SrcIP: 10.0.20.101  TOS: ----
Prot.: ICMP (1)  echo request, id: 0x0400, seq: 0x9b01
Time exceeded => Discard

[IP-Router] 2006/09/06 11:56:07,400
IP-Router Rx (LAN):
DstIP: 10.0.1.111, SrcIP: 10.0.20.101  TOS: ----
Prot.: ICMP (1)  echo request, id: 0x0400, seq: 0x9c01
Time exceeded => Discard

[IP-Router] 2006/09/06 11:56:08,410
IP-Router Rx (LAN):
DstIP: 10.0.1.111, SrcIP: 10.0.20.101  TOS: ----
Prot.: ICMP (1)  echo request, id: 0x0400, seq: 0x9d01
Network unreachable (no route) => Discard

Wenn ich mich via Telnet auf dem Router einlogge und von dort aus Pings
probiere gibts auch von ueberall her eine positive Antwort.

Router Ping ok -> 10.0.1.111 Client im 10.0.1.0-Netz
Router Ping ok -> 10.0.2.10 Server auf dem OpenVPN laeuft
Router Ping ok -> 10.0.20.254 VPN Server auf 10.0.2.10
Router Ping ok -> 10.0.20.101 VPN Client

In der Routing Tabelle auf dem Router sind folgende Routen hinterlegt:

Code: 
IP-Address Netmask Active Router Distance Mask.
10.0.20.0 255.255.255.0 YES 10.0.2.10 0 OFF
224.0.0.0 224.0.0.0 YES 0.0.0.0 0 OFF
255.255.255.255 0.0.0.0 YES INTERNET 0 ON

Die Routen fuer das 10.0.1.0 und 10.0.2.0 Netz setzt er automatisch.

Wie gesagt mit dem tcpdump Befehl kenne ich mich nicht aus und weiss nicht
wie genau ich diesen anwenden muss um ein Ergebnis angezeigt zu bekommen.
 
OpenVPN Verbindung wird getrennt.

Hallo Zusammen,

ich habe folgendes Problem, was ich nicht lösen kann. Auf Eure Tipps und Ratschläge freue ich mich sehr.

Die VPN Verbindung via OpenVPN 2.0.8 wurde zwischen zwei Filialen aufgebaut, die Verbindung hält aber leider ca. max. 2 Stunden und wird seitens VPN- CLIENT zwangsläufig getrennt.

Die VPN- Trennung ist mit dynamischer WAN IP Wechsel verbunden, der Router bekommt neu IP Adresse aus welchem Grund auch immer zugewiesen. Unser Internet- Provider macht keine Zwangstrennung, es wurden mehrere und gleichzeitige PPPOE Sessionen beim Provider festgestellt. Laut unserem Provider ist es ungewöhnlich.

Nach dem WAN IP- Wechsel funktioniert die VPN- Verbindungsaufbau auf dem Client nicht mehr, aber wenn ich client.ovpn auf anderem Rechner ausführe, wird die Verbindung direkt aufgebaut. Total seltsam :confused:

Es könnte natürlich am Router liegen, den wollte ich heute Abend auswechseln und mit anderem ausprobieren. Aber wenn nicht, was könnte es dann sein?

Es ist nicht ausgeschlossen, dass ich paar Details übersehen habe.

Hier sind meine Configs:

ovpn.server

port 1194
proto udp
dev tap
tls-server
mode server
ifconfig 10.0.2.1 255.255.255.0
ifconfig-pool 10.0.2.5 10.0.2.10 255.255.255.0
push "route 10.0.2.0 255.255.255.0"
push "route 192.168.100.0 255.255.255.0"
push "ping 10"
push "ping-restart 60"
push "ping-timer-rem"
tun-mtu 1500
tun-mtu-extra 32
client-to-client
dh C:\\Programme\\OpenVPN\\easy-rsa\\keys\\dh1024.pem
ca C:\\Programme\\OpenVPN\\easy-rsa\\keys\\ca.crt
key C:\\Programme\\OpenVPN\\easy-rsa\\keys\\server1.key
cert C:\\Programme\\OpenVPN\\easy-rsa\\keys\\server1.crt
keepalive 10 120
ping-timer-rem
persist-key
persist-tun
comp-lzo
verb 4

openvpn.client

remote xxxyyy.dyndns.org
port 1194
dev tap
tun-mtu 1500
tun-mtu-extra 32
tls-client
ca C:\\Programme\\OpenVPN\\easy-rsa\\keys\\ca.crt
key C:\\Programme\\OpenVPN\\easy-rsa\\keys\\client1.key
cert C:\\Programme\\OpenVPN\\easy-rsa\\keys\\client1.crt
ns-cert-type server
persist-key
persist-tun
mute 50
pull
comp-lzo
verb 4


Vielen Dank für Eure Hilfe im Voraus!!!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben