VPN-Verbindung nach Zwangstrennung steht, aber kein Traffic

[Schmal]

Tach zusammen,
Situation:
1681V als Zentralrouter, der Site2Site-VPNs zu 6 x 1631E unterhält. Alle (bis auf eine Außenstelle über dyn. DNS, aber vernachlässigen wir den mal) mit festen IP-Adressen.
Zentralrouter hat VDSL + SDSL mit LOADBAL (Firewall-Tag 1 für SMTP über SDSL, Tag 2 für FTP- und WEB-Dienste über VDSL),
VPNs werden nur von den Außenstellen aufgebaut und kommen ausschließlich über die IP des VDSL herein. Kein dyn. VPN, main mode, DPD 60.

Das alles lief einwandfrei seit langer Zeit, dann haben wir aller Router auf die neue Firmware gehoben:
8.62 => 8.84 => 9.04 => 9.10.0382RU1 (Zwischenschritte auf Anweisung vom LANCOM-Support).
Seit dieser Zeit haben wir immer mal wieder die eine oder andere Außenstelle, die morgens plötzlich keinen Datenverkehr (Ping, RDP) mehr zum zentralen LAN durchbringt.
Eine manuelle Trennung der entsprechenden VPN-Verbindung behebt das Problem dann. Bis zum nächsten Mal, wann auch immer.
Am 29.11. haben wir dann nochmals alle Router von 9.10.0382RU1 auf 9.10.0426RU3 aktualisiert, aber der Fehler trat unterdessen schon wieder auf.

Nun fiel mir bei der provisorischen Behebung auf, daß der LANMonitor im Fehlerfall zeigte, die betroffene Außenstelle sei über den Anschluß LOADBAL verbunden, alle anderen zeigten die Schnittstelle VDSL, wie eigentlich erwartet. Deshalb wollte ich Euch fragen, ob ich da in die richtige Richtung fahnde.
Als vernünftiger Forenbenutzer sucht man aber erst einmal, ob das Problem schon bekannt ist und ich stieß u. a. darauf:
(http://www.lancom-forum.de/fragen-zum-t ... tml#p81682):
Zitat Jirka:
"Unter gewissen Konstellationen gibt es bei Nicht-Dynamic-VPN-Verbindungen das bekannte Problem, dass eine der beiden Seiten trotz DPD meint, die Verbindung würde noch bestehen, obwohl sie nicht mehr besteht. Diese Seite lehnt dann den Einwahlversuche der anderen Seite ab und so wird die VPN-Verbindung nicht mehr funktional aufgebaut. Hier hilft es auf der Seite, wo die Verbindung noch besteht, eine manuelle Trennung (z. B. mit LANmonitor oder auf der Konsole) durchzuführen. Anschließend kann die Verbindung ohne Probleme aufgebaut werden."

@ Jirka: was genau sind die "bestimmten Konstellationen"?
Vielleicht ist es ja auch ein ganz anderes Problem...?

Bin für jeden Rat dankbar!

Gruß
Schmal

[Dr.Einstein]

Hallo Schmal,

das von Jirka beschriebene Problem ist leicht zu erkennen. Du schaust mittels Monitor auf beide Router rauf. Wenn beide VPN grün anzeigen ist es nicht der genannte Bug. Wenn Zentrale sagt iO und der Außenstandort versucht alle 30 Sekunden erfolglos aufzubauen, dann hat die Zentrale nicht mitbekommen, dass der Tunnel weg ist (siehe Bug Jirka).

In deinem Fall würd ich mal Richtung Routing schauen.

In der VPN Verbindungsliste der Zentrale, sind dort alle VPNs mit Routing Tag 2 hinterlegt? Wenn nicht, nachtragen.

Gruß Dr.Einstein

[Schmal]

Hallo Dr. Einstein,

richtig, bei mir sind alle Verbindungen grün, also ist es nicht das Thema, das Jirka beschrieb.

Ich habe alle Routen zu den Außenstellen ohne Tag in der Tabelle, nur der "Router" SDSL hat dor Tag 1, VDSL hat Tag 2, plus einer Standard-Route ohne Tag (0).
Fast hätte ich "natürlich" geschrieben, aber Deine Frage läßt mich an mir selbst zweifeln... ich bestimme über die Tags doch nur, daß bestimmter, AUSgehender Datenverkehr über bestimmte Schnittstellen herausgeht. Alles andere kann sich über LOADBAL den Weg suchen.
Bei den VPNs geht es aber um EINgehende Verbindungen, die nur die VDSL-IP für die Kontaktaufnahme kennen. Welchen Denkfehler habe ich hier? *kopfkratz*

Gruß
Schmal

[Dr.Einstein]

Moment moment, ich rede nicht von der Routing Tabelle, die ist bestimmt schön. Die Routing Einträge für die VPN Zielnetze sind Tag 0, alles i.O.

Ich rede von VPN / Verbindungsliste / Routing Tag. Ist dort 0 oder 2 hinterlegt? Wenn 0, dann mach 2 rein. Es gibt Fälle, wo ein VPN Aufbau nicht direkt beim 1. Mal klappt. Durch die PPP Liste etc. kann es aus welchen Gründen auch immer mal passieren, dass der Tunnel doch von der Zentrale aus aufgebaut wird, dadurch entsteht dann evtl. der Loadbalancer statt VDSL.

Ist nur so eine Idee.

Gruß Dr.Einstein

[Schmal]

Die Hilfe zu dem Feld lautet:
"Geben Sie hier das Routing-Tag an, mit dem die Routen zu allen entfernten Gateways ermittelt werden, welche kein eigenes Routing-Tag konfiguriert haben (d.h. bei denen das Routing-Tag 0 ist)."
Nicht, daß mir das zu viel sagen würde... ich muß dringend mal wieder einen Auffrischungskurs bei LANCOM belegen. Das wird zunehmend Blindflug...

Das Tag 2 an diesen Stellen (mehrere VPNs) muß ich dann unter kontrollierten Bedingungen testen, da ich nicht morgen früh den GAU erleben möchte. Ich könnte dann ja testweise den Aufbau von der Zentrale durchführen lassen, dann kann ich das Fehlerbild nachstellen.
Die Idee ist absolut plausibel, vielen Dank! Wenn ich Ergebnisse habe, werde ich sie hier veröffentlichen.

Gruß
Schmal

[Dr.Einstein]

Im Prinzip hast du mit der Beschriftung Recht, das lehren auch die Kurse so. Das Problem ist ja eher, dass Theorie (Kurs) und Realität (siehe dein Fehler) etwas auseinander gehen

[Bernie137]

Hallo Schmal,

prüfe doch mal, ob es mir der Firmware 9.04RU4 eventuell ohne Probleme läuft. Du kannst Dich hier auch informieren, warum ich Dir das empfehle.

vg Bernie

[5624]

Versuch doch mal eine andere DPD-Zeit. Ich bin der Meinung, mit der DPD-Zeit 60 stimmt irgendwas nicht. Hab damit auch schon häufiger Probleme gehabt, ist egal, ob 30, 45 oder 90, solange es nicht 60 ist.

[Schmal]

@ Bernie137: Werde ich sicher in Betracht ziehen, sollte das Tag 2 keine Plausibiltät liefern. Da diverse Router betroffen sind, möchte ich den Zeitaufwand für den Kunden nicht noch höher treiben, wenn nicht unbedingt erforderlich.

@ 5624: Darauf hätte ich normalerweise mit einer Anfrage nach Deinem Glaskugellieferanten geantwortet. Aber seitdem ich mit einem Admin-Kennwort, das einen Unterstrich enthielt, vollends auf die Nase gefallen bin (kein Zugriff mehr, nachdem die gesamte Konfig fertig war), erscheint mir sogar das nicht mehr abwegig.

Dank an alle für das Interesse, ich melde mich zurück!

Gruß
Schmal

[5624]

@ 5624: Darauf hätte ich normalerweise mit einer Anfrage nach Deinem Glaskugellieferanten geantwortet. Aber seitdem ich mit einem Admin-Kennwort, das einen Unterstrich enthielt, vollends auf die Nase gefallen bin (kein Zugriff mehr, nachdem die gesamte Konfig fertig war), erscheint mir sogar das nicht mehr abwegig.

Explizites Beispiel: Mainmode-Verbindung, VPN-Verbindung mit mehr als einem entfernten Gateway (explizit waren es zweimal zwei, jeweils mit unterschiedlichen Routingtags, tritt aber auch auf, wenn nur zwei angelegt sind, eingestellt auf "Anfangen mit Gateway: Erstem"). DPD steht auf 60 Sekunden. Wenn jetzt das Gateway stirbt und DPD erkennt, dass es tot ist, erfolgt kein Sprung zum zweiten, dritten, ... Gateway. Hier kann man warten bis man schwarz wird. Wenn irgendwas anderes statt DPD 60 Sekunden eingestellt ist, funktioniert es problemlos.
Das Beste an der Sache: Ein LANCOM-Trainer hat es auch schon live mitbekommen.

[Bernie137]

Hi,

Explizites Beispiel: Mainmode-Verbindung, VPN-Verbindung mit mehr als einem entfernten Gateway (explizit waren es zweimal zwei, jeweils mit unterschiedlichen Routingtags, tritt aber auch auf, wenn nur zwei angelegt sind, eingestellt auf "Anfangen mit Gateway: Erstem"). DPD steht auf 60 Sekunden. Wenn jetzt das Gateway stirbt und DPD erkennt, dass es tot ist, erfolgt kein Sprung zum zweiten, dritten, ... Gateway. Hier kann man warten bis man schwarz wird. Wenn irgendwas anderes statt DPD 60 Sekunden eingestellt ist, funktioniert es problemlos.

Das ist eine interessante Aussage. Ich hab ja einen VPN Load Balancer am Laufen. Seit drei Tagen kommen früh nach der Zwangstrennung zwei Bündel nicht hoch, keine Änderungen an der Konfig. Trenne ich von Hand die beiden VPN Tunnel im LANmonitor werden diese sofort aufgebaut. Hab gestern mal die DPD von 60 auf 45 geändert. Heute morgen läuft es ohne Murren. Werde das mal beobachten.

vg Bernie

[Schmal]

Tach zusammen,
eindeutige Diagnose: immer wenn die Verbindung über die Zentrale (LOADBAL) aufgebaut wurde, liefen keine Daten darüber. Nach dem Setzen des VPN-Tags 2 (VDSL, worüber sie auch hereinkommen) für die VPN-Verbindungen passierte das nicht mehr.
Vielen Dank, Dr. Einstein!

Die DPD-Zeit habe ich erst einmal absichtlich nicht geändert (ist überall 60), damit die Zukunft zeigen kann, ob das evtl. noch ein separates Problem ist. Erstmal nur an einer Stellschraube drehen...