[Ungelöst] Problem bei VPN: Ziel-IP wird nicht korrekt erreicht

Rickyman

Enthusiast
Thread Starter
Mitglied seit
23.02.2010
Beiträge
469
Hallo,
ich habe zwischen drei Routern ein VPN laufen (Draytek-Vigor 2865). A-B-C

Die Verbindung A-B und B-A ist problemfrei. Das bedeutet, ich kann z.B. per IP das jeweilige NAS oder eine Kamera aufrufen.
Die Verbindung von C zu A oder B ist ebenfalls OK.
Jedoch kann von A und B keine vernünftige Verbindung zu den Geräten bei C aufgebaut werden. Wobei die physikalische Verbindung als solches durch die Router
als korrekt bezeichnet wird. Auch der Abgleich zwischen den drei NAS läuft problemfrei im Hintergrund. Aber ich kann von A oder B keine IP auf C aufrufen.
Das dauert entweder sehr lange oder geht gar nicht. Es kommt auch keine Fehlermeldung. Es erscheint eine weiße Seite...

Ich hoffe, das Problem ist zu verstehen; wenn nicht formuliere ich noch mal um. :-)


Hat jemand eine Idee?

(Alle Endgeräte und die Router verfügen über aktuellste Updates)
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wie sind die Geräte miteinander verbunden?
Im selben LAN oder über das Internet?

Wie sieht ein Traceroute A-B, A-C, B-C aus?

Was für ein VPN wird genutzt?
Welche IP Netze werden auf Seite A, auf Seite B, auf Seite C genutzt, welche IPs sind in den Tunneln vergeben?

Auf was steht die MTU in den VPNs?
 
Hallo, die drei Standorte sind über das Internet verbunden.

Tracerout A-C:
Routenverfolgung zu 192.168.6.41 über maximal 30 Hops

1 <1 ms <1 ms <1 ms 192.168.2.1 (A, Start)
2 9 ms 14 ms 9 ms 192.168.4.1 (über B)
3 16 ms 15 ms 15 ms 192.168.6.41 (Ziel C)

Interessanterweise sind die Router A und B aber nicht C zu sehen.
Müsste nicht 192.168.6.1 auch zu lesen sein? Und warum über B?

Tracerout A-B:
Routenverfolgung zu 192.168.4.201 über maximal 30 Hops

1 <1 ms <1 ms <1 ms 192.168.2.1
2 11 ms 8 ms 8 ms 192.168.4.1
3 9 ms 8 ms 8 ms 192.168.4.201

Das sieht hingegen plausibel aus.

C ist derzeit zu weit weg, als das ich dort einen Trace auslösen kann. Es gibt auch
keine Remotezugriff.

Verbindung läuft über IPsec.

MTU
A: 1492
B: 1492
C: 1492
Beitrag automatisch zusammengeführt:

Ich müsste aber wohl noch ergänzen erklären:

An jedem Standort gibt es eine Fritzbox; dieser ist jeweils der Draytek nachgeschaltet.

FB wird für die Telefonie benötigt. Zudem konnte die FB das VPN anfänglich nicht schnell genug betreiben, daher die Vigors.

Ich habe mal einen Trace von A nach C gestartet; dann kommt das:

Routenverfolgung zu 192.168.5.1 über maximal 30 Hops

1 <1 ms <1 ms <1 ms 192.168.2.1
2 1 ms 1 ms 1 ms FB5590ZUHAUSE [192.168.0.1]
3 p509280a3.dip0.t-ipconnect.de [xx.xxx.xxx.xxx von mir geixt] meldet: Zielnetz nicht erreichbar.

Ablaufverfolgung beendet.

Von A nach B sieht es korrekt aus.
 
Zuletzt bearbeitet:
So, heute bin ich am anderen Standort (B).

Das sieht auch merkwürdig aus:

C:\Users\Anmeldung>tracert 192.168.6.41

Routenverfolgung zu 192.168.6.41 über maximal 30 Hops

1 <1 ms <1 ms <1 ms 192.168.4.1 (B)
2 8 ms 16 ms 8 ms 192.168.2.1 (A)
3 16 ms 16 ms 16 ms 192.168.4.1 (B)
4 25 ms 17 ms 23 ms 192.168.6.1 (C)
5 18 ms 18 ms 24 ms 192.168.4.1 (B)
6 18 ms 18 ms 17 ms 192.168.6.41 (C)

Ablaufverfolgung beendet.
 
Also.
Netzwerk A ist die 192.168.2.x mit /24er Subnetz?
Netzwerk B ist die 192.168.4.x mit /24er Subnetz?
Netzwerk C ist die 192.168.6.x mit /24er Subnetz?

Deine Traces sehen für mich nach dem "Klassiker" aus, das die Endgeräte keine Route haben um an das Endgerät zu kommen und eventuell auch eine der beteiligen FB sich nicht sicher ist, wie sie zum Ziel kommt.

Kann man in den Fritzboxen statische Routen angeben?
Wenn ja, wie sehen deine Einträge dort aus?

Alternativ könntest du unter Windows (falls du es nicht schon gemacht hast) in der Kommadozeile über route print sehen welche Wege dein IPv4 Traffic nimmt. Unter Linux über ip route show.
Wenn du dann mal testen möchtest was passiert wenn du die Routen unter Windows mit route add ZIELIP mask SUBNETZMASKE GATEWAYIP hinzufügst, das könnte schon helfen. Unter Linux dazu analog ip route add ZIELNETZIP(/MASKE) via GATEWAYIP.

Und ja, eigentlich sollte bei Zugriff auf ein Subnetz im Traceroute immer auch das jeweilige Gateway stehen, es sei denn dein Traceroute läuft über einen bestehenden Tunnel, das wäre dann auch eine Möglichkeit die die "merkwürdigen" Traces erklären könnte.
 
Hallo Zyxx,
die Auflistung der Netzwerke stimmt.

Mich wundert nur, dass zwischen A und B, sowie von C nach A oder B alles bestens ist. Nur von A oder B nach C geht es nicht. Euren bisherigen Antworten und meiner Logik
nach, sollte der Fehler wohl bei C liegen oder?

Ja, man kann in den FB statische Routen eingeben.

Noch mal zur Info, falls ich mich nicht korrekt ausgedrückt habe:
Die VPNs bilden quasi ein Dreieck; jede Verbindung ist daueraktiv

Route print an A sieht so aus:

===========================================================================
Schnittstellenliste
5...00 d8 61 a6 17 c6 ......Realtek PCIe GbE Family Controller
15...00 1a 7d da 71 15 ......Bluetooth Device (Personal Area Network)
1...........................Software Loopback Interface 1
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.2.1 192.168.2.10 25
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.2.0 255.255.255.0 Auf Verbindung 192.168.2.10 281
192.168.2.10 255.255.255.255 Auf Verbindung 192.168.2.10 281
192.168.2.255 255.255.255.255 Auf Verbindung 192.168.2.10 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.2.10 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.2.10 281
===========================================================================
Ständige Routen:
Keine

IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
5 281 fe80::/64 Auf Verbindung
5 281 fe80::47d2:d1fc:XXXX:XXXX/128
Auf Verbindung
1 331 ff00::/8 Auf Verbindung
5 281 ff00::/8 Auf Verbindung
===========================================================================
Ständige Routen:
Keine


An Standort B:

===========================================================================
Schnittstellenliste
5...e0 d5 5e da 2b 89 ......Intel(R) Ethernet Connection (7) I219-V
1...........................Software Loopback Interface 1
===========================================================================

IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.4.1 192.168.4.201 281
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
192.168.4.0 255.255.255.0 Auf Verbindung 192.168.4.201 281
192.168.4.201 255.255.255.255 Auf Verbindung 192.168.4.201 281
192.168.4.255 255.255.255.255 Auf Verbindung 192.168.4.201 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.4.201 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.4.201 281
===========================================================================
Ständige Routen:
Netzwerkadresse Netzmaske Gatewayadresse Metrik
0.0.0.0 0.0.0.0 192.168.4.1 Standard
===========================================================================

IPv6-Routentabelle
===========================================================================
Aktive Routen:
If Metrik Netzwerkziel Gateway
1 331 ::1/128 Auf Verbindung
5 281 fe80::/64 Auf Verbindung
5 281 fe80::7a19:13f7:XXXX:XXXX/128
Auf Verbindung
1 331 ff00::/8 Auf Verbindung
5 281 ff00::/8 Auf Verbindung
===========================================================================
Ständige Routen:
Keine


An Standort C komme ich von hier derzeit nicht.
 
Zuletzt bearbeitet:
Wer ist 192.168.5.1?
 
N kleines Bildchen mit den Netzen und Sites hilft bei sowas immer um mehr helfendes Publikum anzulocken :)
 
Hilft das?
 

Anhänge

  • Netzwerk_a.jpg
    Netzwerk_a.jpg
    68,5 KB · Aufrufe: 16
Das macht deinen Aufbau verständlicher, ja.

Und von wo nach wo gibt es nun die IPSec Tunnel?
 
Jeder Vigor ist über IPsec mit den beiden anderen verbunden. Das Ganze wurde vor Jahren durch den Support von Draytek eingerichtet.
 
Die Vigors hängen also an einem DSL oder Glasanschluss und spannen untereinander über IPSec ein Netz auf?
Wahrscheinlich über dynamische DNS Einträge gelöst, oder haben die Anschlüsse statische IPs?

Wenn der "c" Vigor nicht erreichbar ist, kann der aber noch a und b erreichen?
Wenn dyndns genutzt wird, welche IP hat der Vigor bei C dann laut dyndns, welche IP hat c wirklich?
 
Mach doch mal Abzüge von den Routingtabelle in den Drayteks.
Die lokalen Geräte an jedem Standort werden an sich keine Probleme haben, da bei denen immer der Draytek als next hop drinsteht.
Ansonsten würde schon das Internet Probleme machen.
Das Problem liegt ziemlich sicher in den Routen zwischen den Drayteks, also über die S2S-Verbindungen.

Ich betreibe auch sowas, mit dem Unterschied, dass meine Drayteks vollen Zugriff auf der Internet haben, ohne vorgeschalteten Router.
Die vorgeschalteten Router sollten aber auch nicht so das Problem sein, insofern die IPSECs sauber laufen. (das kann man ja in den VPN-Oberflächen nachvollziehen, gerne auch nochmal nen Screenshot machen)
Ich habe z.B. nen RIP über den IPSEC laufen, damit auch ne Verbindung/Routing über die nonDirektverbindung zustandekommt.
Beitrag automatisch zusammengeführt:

Spannend ist das hier:
Routenverfolgung zu 192.168.5.1 über maximal 30 Hops

1 <1 ms <1 ms <1 ms 192.168.2.1
2 1 ms 1 ms 1 ms FB5590ZUHAUSE [192.168.0.1]
3 p509280a3.dip0.t-ipconnect.de [xx.xxx.xxx.xxx von mir geixt] meldet: Zielnetz nicht erreichbar.
Wenn zwischen A und C ein IPSEC Tunnel besteht, warum geht das Paket zur .0.1?
Der Tunnel sorgt dafür (müsste), dass die Pakete von der .2.1 direkt über den Tunnel zur .6.1 gehen und da dann im dortigen lokalen outbound Netz enden.
Dieser Trace zeigt, dass die .2.1 keinen Weg zur .5.1 kennt und daher die eigene Defaultroute (die .0.1) nutzt und die .0.1 dann sagt, die .5.1 kenne ich auch nicht, ich schicke das mal zu meinem Defaultrouter (dein Provider, sieht man im Trace) und der Provider sagt dann, ob du nen bisschen bekloppt bist und lokale Netze im Internet pingst und dass dann weghaut.

Also: Schau dir die IPSEC Tunnel an, was da wie tatsächlich läuft und vor allem, welche Routen da (in den Drayteks) existieren.
Ich würde behaupten, dass z.B. in A keine 192.168.5.0/24 drinsteht.

Was passiert denn, wenn man anstelle der 192.168.5.1 die 192.168.6.1 pingt?

Ansonsten macht es auch keinen Sinn die 192.168.5.1 zu pingen (auch bei korrekten Einträgen in den Tabellen der Drayteks), weil in der 192.168.5.1 keine Rückroute zur 192.168.2.0/24 drinsteht. (würde mich zumindest wundern, kann man ja mal checken)

Wenn man sowas testet, dann pingt man alle Drayteks untereinander, nicht die InternetIP sondern die LokalIP. Man pingt nicht die FB.

Also
192.168.2.1->192.168.4.1
192.168.2.1->192.168.6.1
192.168.4.1->192.168.2.1
192.168.4.1->192.168.6.1
192.168.6.1->192.168.2.1
192.168.6.1->192.168.4.1
Da ist dann einiges redundant, zur Sicherheit aber genau so machen.
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh