VPN-Gegenstelle mit dyndns Namen wird nicht aktualisiert

[Hagen2000]

Wir haben mehrere VPN-Gegenstellen, die keine feste IP-Adresse haben, sondern über dyndns aufgelöst werden. Hin und wieder kommt es vor, dass der Verbindungsaufbau von einer dieser Gegenstellen nicht möglich ist. Eine erste Analyse hat folgendes ergeben:
In der Trace-Ausgabe wird für die funktionierende Gegenstelle regelmäßig (so alle 7 bis 8 Minuten) ein VPN-Status mit folgender Form aufgezeichnet:

Code: Alles auswählen

starting external DNS resolution for XXX;IpStr=YYY, IpAddr(old)=a.b.c.d, IpTtl(old)=60s

Für die nicht-funktionierende Gegenstelle fehlt dieser regelmäßige Eintrag.
Ein show vpn über das CLI zeigt für die betroffene Gegenstelle unter anderem:

Code: Alles auswählen

Remote Gateway:             IPV4_ADDR(any:0, 0.0.0.0)

Somit scheint die Aktualisierung der IP-Adresse zu für diese Gegenstelle nicht mehr stattzufinden.

Ich habe nun folgende Fragen:

a) Kann man im LCOS irgendwo eine Art "Schedule" einsehen, welche Adressen regelmäßig aktualisiert werden müssen?

b) Wie kann man das für eine konkrete Gegenstelle wieder anstoßen, ohne den Router neu zu starten?

c) Gibt es einen Bug im LCOS, dass das Problem überhaupt auftritt oder liegt ggf. irgendwo eine Konfigurationsfehler vor?

d) Welcher Zyklus liegt der regelmäßigen Abfrage zugrunde? Der Ablauf der TTL (60s) scheint es ja nicht zu sein, da die Aktualisierung nur alle 7 bis 8 Minuten stattfindet.

Für jeden Tipp bin ich dankbar!

Router: LANCOM 1781VA mit LCOS 9.20.0566Rel

[MariusP]

Hi,
TTL bezeichnet die Anzahl an Hops auf dem Weg die das Paket zurücklegen darf.

Du baust von der Zentrale zu den Filialen her auf?
Gruß

[Hagen2000]

Hi,

der Verbindungsaufbau erfolgt von den Filialien (mit dyndns) zur Zentrale, es wird der Main Mode benutzt.

P.S.: Nach meiner Kenntnis bedeutet TTL = Time to Live, siehe auch https://de.wikipedia.org/wiki/Time_to_Live zur Bedeutung beim DNS.

[Hagen2000]

Nachtrag: Im Syslog habe ich - zeitlich ab dem Beginn der Störung - folgenden Eintrag gefunden:

Code: Alles auswählen

<Zeitstempel> CONNECTION Alarm VPN: License limit of 5 connections exceeded

Der Eintrag taucht mehrfach auf, womöglich bei jedem Einwahlversuch der Gegenstelle.
Es ist aber nur eine einzige VPN-Verbindung aktiv (sieben sind insgesamt konfiguriert, einige davon historisch).

[kirdes]

Hi,

Das Problem hab ich auch ab und zu. Ich hatte hier im Forum dazu auch ein Thema eröffnet, allerdings leider ohne Lösung.
Im VPN-Trace fehlt bei mir der Eintrag für die Auflösung des dyndns Names.
Hat sich nun in der Zwischenzeit die IP-Adresse der Gegenstelle geändert, funktioniert die VPN-Version Verbindung nicht mehr, da der betreffende Router noch mit der vorhergehenden IP-Adresse arbeitet.

Als Workaround logge ich mich per SSH über WAN ein und deaktiviere und aktiviere die betroffene VPN-Verbindung.
Dan erfolgt wieder eine Auflösung des dynDNS Namens.

[Hagen2000]

Hi kirdes,

meinst Du diesen Beitrag: http://www.lancom-forum.de/post79131.ht ... DNS#p79131
Den hatte ich auch schon gelesen, aber ich wollte mich nicht an einen alten Thread hängen.

Deinen Workaround habe ich nicht ganz verstanden: Welche Befehle genau verwendest Du zum Deaktivieren / Aktivieren der VPN-Verbindung? Der LAN-Monitor zeigt bei mir überhaupt keine Verbindung an, die man trennen könnte.

Sind die anderen Cracks alle noch im Sommerurlaub???

[Jirka]

Hallo Hagen2000.

Zu a): Nein.
Zu b): Verbindungstrennung würde auch gehen.
Zu c): Ja, Konfigurationsfehler. (Sorry, habe keine Zeit das hier ausführlich darzulegen. Schreib mir eine E-Mail, wenn Du selber nicht weiter kommst, dann machen wir kurz TeamViewer/AnyDesk o. ä.)
Zu d): LANCOM hält sich da nicht an die TTL. Begründung ist, dass bei 1.000 VPN-Gegenstellen der DNS-Server geflutet werden würde.

Viele Grüße,
Jirka

[GrandDixence]

Code: Alles auswählen

<Zeitstempel> CONNECTION Alarm VPN: License limit of 5 connections exceeded

Wahrscheinlich wird dieses Problem durch die fehlende oder fehlerhafte Konfiguration von Dead-Peer-Detection (DPD) ausgelöst. Siehe dazu das entsprechende Kapitel (17.1.1) im LCOS-Referenzhandbuch:

https://www.lancom-systems.de/docs/LCOS ... 52322.html

http://www.lancom-forum.de/fragen-zum-t ... tml#p86789

Die vom Assistenten eingerichteten Aktionstabellen-Einträge für Dynamisches DNS (z.B. DynDNS, Spdns.de) sind in der Regel fehlerhaft. Ich empfehle die Nutzung von Spdns.de gemäss der Anleitung:

http://www.lancom-forum.de/fragen-zum-t ... tml#p86775

[GrandDixence]

Hat sich nun in der Zwischenzeit die IP-Adresse der Gegenstelle geändert, funktioniert die VPN-Version Verbindung nicht mehr, da der betreffende Router noch mit der vorhergehenden IP-Adresse arbeitet.

Beim Einsatz von IKEv2/IPSec mit MobIKE "überlebt" der VPN-Tunnel auch einseitige IP-Adresswechsel. Siehe auch:

http://www.lancom-forum.de/fragen-zum-t ... tml#p86777

https://www.heise.de/security/artikel/M ... 70948.html

[Hagen2000]

Zu b): Verbindungstrennung würde auch gehen.

Welche Verbindung ist gemeint? Die VPN-Verbindung besteht ja gar nicht mehr. Oder ist die DSL-Verbindung gemeint? Diese wird ohnehin einmal am Tag zwangsweise getrennt.

Zu c): Ja, Konfigurationsfehler. (Sorry, habe keine Zeit das hier ausführlich darzulegen. Schreib mir eine E-Mail, wenn Du selber nicht weiter kommst, dann machen wir kurz TeamViewer/AnyDesk o. ä.)

Danke für das Angebot! Ich werde gerne darauf zurückkommen, falls ich es selber nicht weiter komme.

Zu d): LANCOM hält sich da nicht an die TTL. Begründung ist, dass bei 1.000 VPN-Gegenstellen der DNS-Server geflutet werden würde.

Leuchtet ein, Danke für die Infos.

[Hagen2000]

Wahrscheinlich wird dieses Problem durch die fehlende oder fehlerhafte Konfiguration von Dead-Peer-Detection (DPD) ausgelöst. Siehe dazu das entsprechende Kapitel (17.1.1) im LCOS-Referenzhandbuch:

Habe ich geprüft. Ist m.E. alles in Ordnung. Außerdem ist die VPN-Verbindung LANCOM-seitig ja nicht vorhanden / abgebaut!
Im übrigen benutze ich nicht IKEv2.

Die vom Assistenten eingerichteten Aktionstabellen-Einträge für Dynamisches DNS (z.B. DynDNS, Spdns.de) sind in der Regel fehlerhaft. Ich empfehle die Nutzung von Spdns.de gemäss der Anleitung:

Danke für den Tipp. Auch hier scheint aber alles in Ordnung zu sein. Und es geht nicht um den eigenen bei DynDNS registrierten Namen, sondern um den der VPN-Gegenstelle, die sich einwählen will. Nach meinem Verständnis hat die Aktionstabelle damit gar nichts zu tun.

[Bernie137]

Hallo Hagen2000,

dyn VPN ist keine Option für Euch? Damit umgeht man dyn DNS, bei uns klappt das super.

Gruß Bernie

[Jirka]

Hallo,

Code: Alles auswählen

<Zeitstempel> CONNECTION Alarm VPN: License limit of 5 connections exceeded

Wahrscheinlich wird dieses Problem durch die fehlende oder fehlerhafte Konfiguration von Dead-Peer-Detection (DPD) ausgelöst.

was ist denn auf der Gegenseite, auch ein LANCOM-Router?
Vgl. auch: http://www.lancom-forum.de/fragen-zum-t ... tml#p84611

Viele Grüße,
Jirka

[Hagen2000]

Hallo Jirka,

die Gegenseite ist eine FRITZ!Box mit FRITZ!OS 6.50. Der VPN-Zugang arbeitet - wie schon beschrieben - im main mode (phase1_mode_idp heißt das bei der FB).

Kannst Du auf diesen Beitrag, Frage zu Punkt b) von mir auch nochmal schauen?
http://www.lancom-forum.de/aktuelle-lan ... tml#p86917

[Jirka]

Hallo Hagen,

ja, wenn die Gegenseite eine FRITZ!Box ist, dann ist ja mit meinem Link alles gesagt. Willkommen im Club

Zur Nachfrage zu Punkt b): Ja, ich meinte schon die VPN-Verbindung. Wenn die natürlich nicht mehr besteht...
Ich weiß nicht, ob Du die Auflösung der DynDNS-Namen dadurch forcieren kannst, dass Du in der Zentrale auch einen aktiven Verbindungsaufbau durchführst. Eine weitere Idee wäre die anderen (nicht mehr genutzten, soweit ich das verstanden habe) VPN-Verbindungen zu löschen oder den DynDNS-Namen da raus zu nehmen. Eine dritte Idee - von der verspreche ich mir den größten Erfolg - ist, die "Weitere entfernte Gateways"-Tabelle 33 mal mit dem gleichen DynDNS-Namen zu bestücken (vielleicht sollte man es erst mal mit 5 mal probieren).

Viele Grüße,
Jirka