VPN-Gegenstelle mit dyndns Namen wird nicht aktualisiert

[kirdes]

@Hagen2000

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.

ich logge mich per SSH ein und gehe nach /Setup/VPN/IKEv2/Peers (ja ich verwende IKEv2) und deaktiviere hier den entsprechenden Eintrag und aktiviere ihn wieder. Müßte bei ikev1 auch gehen, wobei ich da jetzt auf Anhieb keinen Eintrag (aktiv/inaktiv) gefunden habe.

@Jirka

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.

Genau das funktioniert auch nicht, da auf der anderen Gegenstelle ja noch die veraltete IP-Adresse in den Netzbeziehungen steht (show VPN) und diese dadurch die VPN-Anwahl von der Zentrale ablehnt.

@GrandDixence

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

Wie oben geschrieben, tritt das Problem auch bei IKEv2 Verbindungen auf. Außerdem finde ich bezüglich MOBIKE keine Option im Lanconfig.
Für mein Verständnis müßte das ja auch auf Client-Seite (bei Client-Server Verbindungen) implementiert sein. Wir reden hier doch aber von LAN-LAN Kopplungen. Bin mir nicht sicher, ob hier MOBIKE überhaupt funktioniert.

[Hagen2000]

@Hagen2000

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.

ich logge mich per SSH ein und gehe nach /Setup/VPN/IKEv2/Peers (ja ich verwende IKEv2) und deaktiviere hier den entsprechenden Eintrag und aktiviere ihn wieder. Müßte bei ikev1 auch gehen, wobei ich da jetzt auf Anhieb keinen Eintrag (aktiv/inaktiv) gefunden habe.

Du meinst wahrscheinlich /Setup/VPN/VPN-Peers. Hier finde ich allerdings auch nichts zum Aktiv-/Inaktivschalten.

[Jirka]

Hallo kirdes,

Müßte bei ikev1 auch gehen, wobei ich da jetzt auf Anhieb keinen Eintrag (aktiv/inaktiv) gefunden habe.

Das erfolgt über den Parameter Regelerzeugung/Rule-creation.

Genau das funktioniert auch nicht, da auf der anderen Gegenstelle ja noch die veraltete IP-Adresse in den Netzbeziehungen steht (show VPN) und diese dadurch die VPN-Anwahl von der Zentrale ablehnt.

Klingt bei Dir aber so, als ob Du auf beiden Seiten einen LANCOM hast. Dann hast Du definitiv was falsch gemacht.

Viele Grüße,
Jirka

[Hagen2000]

Hallo Hagen,

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

Also ich finde in dem verlinkten Beitrag nichts, was für meinen Fall relevant ist.

Ich habe das Syslog nochmals durchgeschaut und vor der Lizenzwarnung kommen stets noch andere Meldungen, vermutlich liegt eher dort die Ursache:

Code: Alles auswählen

2016-09-11 19:22:10 SYSTEM Error attribute_unacceptable: conf_match_num failed, type [14]: Undefined error: 0;
2016-09-11 19:22:13 SYSTEM Error last message repeated 15 times;
2016-09-11 19:22:14 CONNECTION Alarm VPN: License limit of 5 connections exceeded;

Diese drei Meldungen treten bei jedem fehlgeschlagenen Verbindungsversuch auf.

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.

Wie schon kirdes geschrieben hat, funktioniert das nicht.

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.

Die anderen VPN-Verbindungen benutzen teilweise statische IP-Adressen bzw. sind für die Einwahl mit Mobilgeräten vorgesehen und haben daher mit DynDNS nichts am Hut.

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).

Das schaue ich mir mal an.

[kirdes]

Hallo Jirka

Klingt bei Dir aber so, als ob Du auf beiden Seiten einen LANCOM hast. Dann hast Du definitiv was falsch gemacht.

Ja ich habe auf beiden Seiten einen Lancom und die LAN-LAN Kopplung mittels IKEv2 anhand der Knowledge Base eingerichtet.

Zu 99% funktioniert das ja auch problemlos, nur manchmal tritt halt das beschrieben Problem der fehlenden dynDNS Namensauflösung auf.

Das hatte ich auch schon mit IKEv1.

[MariusP]

Hi,
Mobike wird im LCOS noch nicht unterstützt. Der AVC kann dies allerdings schon.
Daher wirst du dazu auch im Lanconfig/CLI nichts finden können.
Aktuell bzw in der letzten Zeit sind andere Sachen im Bereich VPN von größerem Interesse.

ich logge mich per SSH ein und gehe nach /Setup/VPN/IKEv2/Peers (ja ich verwende IKEv2) und deaktiviere hier den entsprechenden Eintrag und aktiviere ihn wieder. Müßte bei ikev1 auch gehen, wobei ich da jetzt auf Anhieb keinen Eintrag (aktiv/inaktiv) gefunden habe.

Der Lancom wird bei dem geweiligen Setzen der Tabelle merken, das sich etwas geändert hat. Wenn er nun feststellt das der Wert für die Verbindung nicht auf aktiv gesetzt ist, wird das weiter unten die Verbindung abbauen. Beim nächsten Setzen wird er wieder merken, das sich was geändert hat und dem entsprechend aufbauen. Die Auswirkungen davon kann man gut im VPN-Status-Trace verfolgen.
Alle Verbindungen kannst du übrigens über VPN/Operating schalten auch "an/abschalten".

Das erfolgt über den Parameter Regelerzeugung/Rule-creation.

Hier ist der passende Schalter mit dem möglichen Wert "Off"

Code: Alles auswählen

root@LC1781EF______MP:/Setup/VPN/VPN-Peers/1781_2
> set ? Rule-creation

Possible input for columns in table 'VPN-Peers' with prefix 'Rule-creation':
[  9] Rule-creation : auto (0), manually (1), off (2)

Gruß

[GrandDixence]

Mobike wird im LCOS noch nicht unterstützt.

Ja, tatsächlich sendet der LANCOM-Router mit LCOS 9.20.0566Rel gemäss VPN-Trace beim vierten IKE-Telegramm (IKE_AUTH) kein MOBIKE_SUPPORTED an den Verbindungs-aufbauenden VPN-Endpunkt zurück, was er gemäss RFC 4555 machen sollte. Schade!

[MariusP]

Hi,
Warum sollte er es?
Wenn der Lancom es nicht beherrscht, gibt es keinen Grund ein solches mitzuschicken.

Implementations that wish to use MOBIKE for a particular IKE_SA MUST
include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange

Und da es LCOS momentan nicht "wünscht" (da es es momentan noch nicht beherrscht) senden wir natürlich keins.
Gruß