Unerklärliches Problem mit Routing

[ako77]

iGude!

Auf dem anhängenden Bild, habe ich mal mein Problem visuell dargestellt. Irgendwo hakt es im Routing. (?)

Wenn ich vom Netz hinter OpenVPN2 in Richtung Netz hinter LANCOM1 pingen möchte, versackt der "echo request" am LANCOM2. Dieser kann selbst aber ohne Probleme ins Netz 192.168.10.0 (hinter LANCOM1) pingen. Es existieren Firewall-Regeln auf beiden Seiten (LANCOM1 und LANCOM2) die alles erlauben und ich habe keine weiteren Beeinträchtigungen.
Per Trace-Abfrage am LANCOM2 sehe ich, wie gesagt, den echo request von z.B. 10.3.2.106 nach 192.168.10.24. Wieso geht's aber nicht weiter, vor allem, wenn dem LANCOM2 sein Ziel (siehe u.a. Routing Table) bekannt ist?

Weitere Infos im Anschluß und bis hierher erstmal vielen Dank für's Lesen und ich freue mich drauf, wenn mir Jemand helfen kann.

Danke & Gruß
Axel

Das ergeben die Traceroutes:

Code: Alles auswählen

10.3.2.106:
traceroute 192.168.10.24
traceroute to 192.168.10.24 (192.168.10.24), 30 hops max, 60 byte packets
1  10.3.2.10 (10.3.2.10)  1.038 ms  0.783 ms  0.483 ms
2  * * *
3  * * *

Code: Alles auswählen

OpenVPN2:
traceroute 192.168.10.24
traceroute to 192.168.10.24 (192.168.10.24), 30 hops max, 60 byte packets
 1  10.0.0.1 (10.0.0.1)  63.602 ms  63.205 ms  62.921 ms
 2  * * *
 3  * * *

Nächster funktioniert und belegt, dass LANCOM2 sein Ziel kennt:

Code: Alles auswählen

OpenVPN1:
traceroute 192.168.10.24
traceroute to 192.168.10.24 (192.168.10.24), 30 hops max, 60 byte packets
1  LANCOM2 (192.168.200.254)  6.881 ms  6.864 ms  6.847 ms
2  192.168.10.254 (192.168.10.254)  88.402 ms  92.260 ms  93.882 ms
3  192.168.10.24 (192.168.10.24)  96.155 ms * *

Code: Alles auswählen

192.168.10.24:
C:\Users\Axel>tracert 10.3.2.10
Routenverfolgung zu 10.3.2.10 über maximal 30 Hops
1     1 ms    <1 ms    <1 ms  192.168.10.254
2     *        *     

Nun einmal "tcpdump" an OpenVPN1:

Code: Alles auswählen

tcpdump -nni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
23:19:34.165510 IP 10.3.2.106 > 192.168.10.24: ICMP echo request, id 26541, seq 1, length 64
23:19:35.165717 IP 10.3.2.106 > 192.168.10.24: ICMP echo request, id 26541, seq 2, length 64

Und letztlich der Trace am LANCOM2:

Code: Alles auswählen

trace # eth @ ICMP +"echo"
[Ethernet] 2014/02/03 23:18:05,721
Received 98 byte Ethernet packet via LAN-1:
HW Switch Port      : ETH-1
IPv4 Hdr Checksum   : OK
-->IEEE 802.3 Header
Dest                : 00:a0:57:17:3a:69 (LANCOM 17:3a:69)
Source              : 08:00:27:1a:1b:e1 (Cadmus/Virtualbox 1a:1b:e1)
Type                : IPv4
-->IPv4 Header
Version             : 4
Header Length       : 20
Type of service     : (0x00) Precedence 0
Total length        : 84
ID                  : 0
Fragment            : Offset 0 DontFrag
TTL                 : 62
Protocol            : ICMP
Checksum            : 25980 (OK)
Src Address         : 10.3.2.106
Dest Address        : 192.168.10.24
-->ICMP Header
Msg                 : echo request
Checksum            : 48224 (OK)
Identifier          : 26540
Sequence            : 9
Body                : 9a 15 f0 52 00 00 00 00 ...R....
...

[Pothos]

Hi ako77,

ich vermute es fehlen einfach nur ein paar VPN SAs.
In der LANCOM Knowledgebase ist dein Szenario "in etwa" beschrieben. Die Routen sehen bei dir ja soweit alle vollkommen ok aus. Sprich in dem Dokument reicht für dich der letzte Teil, wo in der Firewall die VPN Regeln angelegt werden. Hoffe das hilft dir weiter. Ansonsten mal auf beiden Seiten einen VPN-Status Trace machen und einen IP-Router/Firewall Trace gefiltert auf den Rechner der den Ping absetzt. Da sollte der Fehler auch hochkommen.

Hier noch der Link zu dem Dokument: Klick!

[ako77]

Hi Pothos,

das war wohl der entscheidende Tipp

Danke, es funktioniert nun. Aber verstanden habe ich es noch nicht, was das mit den SA's (security-association?) aufsich hat?! Bisher habe ich immer nur Firewall-Regeln genutzt, um einem Netz den Zugriff ins andere zu gewähren. Kommen die SA's immer dann zum Einsatz, wenn mehrere 'hintereinanderliegende' Netze geroutet werden müssen??

Danke

Gruß, Axel


EDIT: Ach, stand ja in dem besagten Dokument in der KB
Sollen weitere Netze über den VPN-Tunnel geroutet werden, müssen diese explizit über VPN-Regeln definiert werden, da hierdurch die notwendigen VPN-Policy's ( Security Associations - SA's ) erzeugt werden.
Ist das Lancom-spezifisch?

[MariusP]

Hi,
Ich empfehle dir http://tools.ietf.org/search/rfc4301#page-11 ab Kapitel 4 zu lesen bis einschließlich 4.2 zu lesen.
Du kannst natürlich auch den ganzen Standart lesen, wenn du dich im Bereich IPSEC weiterbilden möchtest.
Wenn du es lieber "simpler" formuliert willst: http://de.wikipedia.org/wiki/IPsec#Verbindungsaufbau
und http://de.wikipedia.org/wiki/Security_Association

Sollen weitere Netze über den VPN-Tunnel geroutet werden, müssen diese explizit über VPN-Regeln definiert werden, da hierdurch die notwendigen VPN-Policy's ( Security Associations - SA's ) erzeugt werden.
Ist das Lancom-spezifisch?

Nun wie (aus welchen Tabellen/Menüeinträgen) die SA erzeugt werden ist nicht fest vorgegeben, daher ist der hier beschriebene Fall Lancomspezifisch, allerdings werden auch andere Hersteller dort ihr eigenes Verfahren haben.

Gruß

[ako77]

Danke Marius,

wieder was gelernt und wieder was zu lesen

Gruß

[garfield0815]

nr so am rande
die routing tags stehen alle auf 0

[ako77]

Ok!?
Ausser bei einem Netz (!) das ich vom Rest getrennt haben wollte, als Gast-WLAN.

Ist das so nicht "richtig" aus Deiner Sicht? So funktioniert zwar alles, aber Anspruch auf Best Practise hat/muss es ja nicht.
Wenn ich sonst alle Netze aus (fast) allen Netzen erreichen möchte, kann man das so machen.

Wie geht's anders, professioneller?