VPN-Mode Active statt Passive, ist das korrekt? Oder warum?

[Jirka]

Hallo zusammen, hallo Backslash,

unter /Status/VPN/Connections gibt es die Spalte Mode, die den Wert Active und Passive annehmen kann, korrigiere mich, wenn ich falsch liege. Active steht dabei für aktiven Verbindungsaufbau, also dass der Router die Initiative ergreift und die Gegenseite kontaktiert, passive für passiven Verbindungsaufbau, der Router wartet also, bis sich die Gegenseite bei ihm meldet. Das System haben wir ja nun auch schon seit Jahrzehnten so, also auch schon vor IKEv2. Was mir aber immer und immer wieder auffällt (letztlich im LANmonitor an der Pfeilrichtung bei der VPN, der diesen Wert ausliest) ist, dass hier mitunter Active steht, obwohl das per Konfiguration/Definition gar nicht sein kann. Ist das nicht ein Bug? Konkret: Die Haltezeit steht auf 0, was ja nicht für einen aktiven Aufbau steht, allerdings dann doch wieder, wenn Daten anliegen, die über die VPN geroutet werden sollen. Nun könnte man die Daten mit einer Firewall-Regel verwerfen ("Aktion nur, wenn Verbindung nicht besteht"), was aber auch wieder scheitert, wenn es Daten sind, die vom LANCOM-Router selbst kommen, z. B. vom VCM. Das nächste Argument ist aber, dass in der Verbindungs-Liste bei der VPN-Verbindung kein Gateway angegeben ist, und in der Liste der weiteren entfernten Gateways auch nicht. Die VPN kann also gar nicht aktiv aufgebaut werden, weil man gar nicht weiß, wohin überhaupt. Und wenn ich nicht weiß wohin, ist dann nicht ein aktiver Verbindungsaufbau per Definition gar nicht möglich? Muss hier also nicht passive stehen in der Tabelle /Status/VPN/Connections? Warum ist das nicht der Fall? Die Gegenseite übernimmt doch definitiv den aktiven Part und dort steht es auch so. Jede Seite behauptet also die aktive zu sein, aber eine kann es doch eigentlich nur, oder? Die Gegenseite, also die, die in Wirklichkeit die VPN aufbaut, hat auch eine dynamische öffentliche IP-Adresse, der Router kann also auch nicht aus irgendwas, wie der eben noch bestehenden VPN-Verbindung mit der IP-Adresse der Gegenseite, schließen. Firmware ist 10.50-RU11 (1781EF+).

Vielen Dank und viele Grüße
Jirka

[backslash]

Ji Jirka,

gute Frage... eigentlich sollte da nur dann "active" drin stehen, wenn er wirklich versucht hat aufzubauen, was ja bei leerm Gateway nicht möglich ist...
veilleicht wird die Verbindung ja bereits als "active" markiert, bevor fegestellt wird, da0 es wegen des fehlernem Gateway gar nicht geht und dann wird vergessen es wieder zu löschen...

Gruß
Backslash

[Jirka]

Hi Backslash,

gute Frage... eigentlich sollte da nur dann "active" drin stehen, wenn er wirklich versucht hat aufzubauen, was ja bei leerem Gateway nicht möglich ist...

also versuchen tut er es ja, denn wie schon begründet, verhindert die Haltezeit von 0 das ja nicht. Im VPN-Status-Trace steht dann auch (vier mal pro Tausendstelsekunde):

Code: Alles auswählen

VPN: connecting to XYZ (0.0.0.0) IKEv2
     gateway unspecified and no dynamic VPN on D- or B-channel

Das geht letztlich so lange, bis im Trace steht:

Code: Alles auswählen

VPN: connecting to XYZ (91.7.85.20) IKEv2

Das heißt offenbar wirklich bis zu dem Moment, wo eben feststeht, welche IP-Adresse die Gegenseite hat. (Der erste Teil der passiven Verhandlung lief also zuvor schon, der im "connecting" mit der konkreten IP-Adresse gemündet ist.)

vielleicht wird die Verbindung ja bereits als "active" markiert, bevor festgestellt wird, dass es wegen des fehlenden Gateways gar nicht geht und dann wird vergessen es wieder zu löschen...

Eigentlich bräuchten Verbindungen, für die es kein Gateway gibt, gar nicht erst (aktiv) aufgebaut werden. Das passiert aber offenbar nicht.
Und wenn es dann in die (tatsächliche) Verhandlung mit der Gegenseite geht, wird also offenbar nicht der Mode aktualisiert, ein passive wird also nie geschrieben, das steht am Anfang drin und wenn es einmal mit active überschrieben ist, dann wird das nicht mehr korrigiert. Kann man das fixen? Ich meine klar, es ist nur ein optisches Problem, aber irgendwie kann man sich auf diesen Wert nicht verlassen, er ist im Zweifel immer auf active. Dann geht man in die Konfig, um das zu ändern und stellt eben fest, dass das gar nicht sein kann.

Insofern müsste tatsächlich ganz am Anfang entweder gar nicht erst versucht werden aufzubauen, wenn es kein Gateway gibt, oder aber es darf dann nicht das active reingeschrieben werden in die Connections-Status-Tabelle. Noch besser wäre aber gar nicht erst aufzubauen oder eben max. einen Versuch, der mit einer entsprechenden Fehlermeldung (Trace/Syslog) quittiert wird und dann ist Schluss. Dann hätten auch ein für alle mal die übergelaufenen Syslog-Dateien ein Ende, denn ein

Code: Alles auswählen

LOCAL0    Error      VPN: Error for peer XYZ: IFC-I-No-channel-available

bringt einen auch nicht weiter, wenn es in ein bis zwei Sekunden 1.700 mal ins Syslog geschrieben wird (auch wenn im Gerät selber ein 'last message repeated 1700 times' steht).

Vielen Dank und viele Grüße
Jirka

23.06.23 11:19 Uhr: Geringfügig überarbeitet, genauere und exaktere Formulierung des Satzes mit dem Moment und zwei andere Sätze gestrichen, die damit überflüssig wurden.

[backslash]

Hi Jirka,

Eigentlich bräuchten Verbindungen, für die es kein Gateway gibt, gar nicht erst (aktiv) aufgebaut werden. Das passiert aber offenbar nicht.

das weiss der Router aber nicht, der den Aufbau antriggert - das weiss maximal das VPN und das hat das Flag tatsächlich zu früh gesetzt...
Ab der nächsten Firmware wird es erst dann gesetzt, wenn ein Aufbau aufgrund der Konfig möglich ist...

Noch besser wäre aber gar nicht erst aufzubauen oder eben max. einen Versuch, der mit einer entsprechenden Fehlermeldung (Trace/Syslog) quittiert wird und dann ist Schluss. Dann hätten auch ein für alle mal die übergelaufenen Syslog-Dateien ein Ende, denn ein

Code: Alles auswählen

LOCAL0    Error      VPN: Error for peer XYZ: IFC-I-No-channel-available

bringt einen auch nicht weiter, wenn es in ein bis zwei Sekunden 1.700 mal ins Syslog geschrieben wird (auch wenn im Gerät selber ein 'last message repeated 1700 times' steht).

das ist ein anders Problem und nicht so einfach zu fixen, da der Router am Ende für jedes empfangene Paket versucht, aufzubauen und dann vom VPN mitgeteilt bekommt, daß es die Verbindung nicht möglich war - und das dann in Bootlog schreibt...

Aber das solltest du mit der Firewall-Regel abfangen können, die Traffic verwirft, wenn die Verbindung nicht aufgebaut ist (denn der VCM wird das ja nicht so oft versuchen)

Gruß
Backslash

[Jirka]

Hallo Backslash,

das weiss der Router aber nicht, der den Aufbau antriggert - das weiss maximal das VPN und das hat das Flag tatsächlich zu früh gesetzt...
Ab der nächsten Firmware wird es erst dann gesetzt, wenn ein Aufbau aufgrund der Konfig möglich ist...

ok, danke, das hört sich gut an. Lässt sich das auch in den 10.50-er Stand noch einbauen, oder ist das zu viel verlangt?

Aber das solltest du mit der Firewall-Regel abfangen können, die Traffic verwirft, wenn die Verbindung nicht aufgebaut ist (denn der VCM wird das ja nicht so oft versuchen)

Also sonstiger Traffic lag mit Sicherheit nicht an. Es war ausschließlich der VCM, der was über die VPN schicken wollte. Für einen längeren Zeitraum kann ich hier jetzt nicht sprechen, ich trennte auf der passiven Seite die VPN manuell und die aktive Seite baut daraufhin wieder auf und dazwischen passiert das. Und auf der passiven Seite hier wird auch nur eine SIP-Leitung versucht zu registrieren.

Das Ausmaß ist wirklich größer als ich dachte. Gestern (einen Tag vor meinem Posting) hatte ich mal den Router neu gestartet, weil ich nach den Änderungen im VPN sicher gehen wollte, dass keine Altlasten mehr aktiv sind. Das änderte aber auch nichts am active/passive der VPN, es blieb beim aktive, wie ja schon geschrieben. Da war die VPN erst nach 2,5 Minuten da (Gegenseite auch mal neu gestartet, dort mit VDSL-Synchronisation). In den zweieinhalb Minuten kam diese Syslog-Meldung über geschlagene 250.000 mal! Das ist doch Wahnsinn. Was soll da bei 10 VPN-Verbindungen, die auf einen Aufbau warten und wo Daten anliegen, passieren?!

Vielen Dank und viele Grüße
Jirka

[backslash]

Hi Jirka,

Lässt sich das auch in den 10.50-er Stand noch einbauen, oder ist das zu viel verlangt?

dank git eigentlich kein Prolem...

n den zweieinhalb Minuten kam diese Syslog-Meldung über geschlagene 250.000 mal! Das ist doch Wahnsinn. Was soll da bei 10 VPN-Verbindungen, die auf einen Aufbau warten und wo Daten anliegen, passieren?!

wenn das 250000 mal im Syslog steht, dann hat es auch 250000 Versuche gegeben, die Verbindung hochzuziehen, es müssen also 250000 Pakete angekommen sein - denn daß der VCM das macht, kann ich mir eigentlich nicht vorstellen (aber der ist nicht meine Baustelle)... Hast du vielleicht in deinem Netz irgendwo eine Schleife gebaut, die jetzt wie ein Teilchenbeschleuniger wirkt?

Gruß
Backslash

[Jirka]

Hallo Backslash,

das weiss der Router aber nicht, der den Aufbau antriggert - das weiss maximal das VPN und das hat das Flag tatsächlich zu früh gesetzt...
Ab der nächsten Firmware wird es erst dann gesetzt, wenn ein Aufbau aufgrund der Konfig möglich ist...

ich habe jetzt die 10.50.1301-RU12 vom 09.10.2023 drin und das Problem existiert leider immer noch. (Eine höhere Major-Version kann ich beim 1781EF+ leider nicht installieren.)
Kannst Du mal bitte schauen, ob der Bugfix es tatsächlich in die 10.50 geschafft hat und wenn nein, das vielleicht doch noch mal anstoßen, in der Hoffnung, dass es noch einen RU geben wird?

Vielen Dank und viele Grüße
Jirka

[backslash]

Hi Jirka

der Fix mit dem zu frühen Setzen des Flags (bzw. mit dem nicht mehr Setzen) ist in der 10.50 vorhanden...

und ganz ehrlich: selbst wenn das Problem ich irgendwie anders noch manifestieren sollte: das ist ein Schönheitfehler und am Ende nicht der Mühe wert...

Gruß
Backslash