10.12.0601 mit fehlendem Polling-Eintrag für IKEv2-Verbindung, VPN kommt nicht hoch

[Jirka]

Hallo,

ich hatte in der Nacht zum Samstag die 10.12.0601 vom 11.12.2018 einspielen lassen, zuvor lief die letzte mir zur Verfügung stehende Beta 10.12.0582 vom 07.11.2018. In der Folge war das gemütliche Frühstück am Samstagmorgen etwas kürzer als für einen Adventssamstag geplant, weil IKEv2-Verbindungen mit "IFC-I-No-poll-table-entry-matched" einfach nicht aufgebaut wurden. Und irgendwie frage ich mich jetzt, habe ich hier die VPN-Verbindungen nicht korrekt konfiguriert und wenn ja, wieso muss ich das so machen, oder ist das ein Bug?

Ich habe also eine IKEv2-VPN-Verbindung, die initial aufgebaut werden soll, also eine Haltezeit von 9.999 Sekunden hat. Als Verbindungs-Parameter ist der DEFAULT-Eintrag zugewiesen (DPD 30 Sek., IPsec-o-HTTPS aus). Wieso muss ich jetzt noch einen Polling-Eintrag haben, damit die Verbindung aufgebaut wird? Die Verbindung wird durch VCM/SIP und PRTG/SNMP sowieso spätestens alle 30 Sek. in Anspruch genommen, ein Polling(-eintrag) ist meiner Meinung nach somit völlig überflüssig.

Und kann mir jemand in dem Zusammenhang noch mal kurz die Prüfmethoden der IKEv2-VPNs nennen? DPD gibt es ja anscheinend nach wie vor. Wann wird DPD verwendet, wann Polling? Werden Einträge in der PPP-Tabelle ausgewertet? (Vgl. die entsprechende Diskussion für IKEv1 hier ff.)

Vielen Dank und viele Grüße,
Jirka

[backslash]

Hi Jirka,

der Poll-Eintrag wird bei einer VPN-Verbindung dann benötigt, wenn die Haltezeit 9999 ist UND die SA-Erzeugung nicht auf "Immer alle gemeinsam" oder "Gemeinsam für Keep-Alive" steht, also auf "jede einzeln nach Bedarf"... Denn dann wird tatsächlich ein Datenpaket benötigt, um die SAs aufbauen zu können und das wird vom ICMP-Polling geliefert.

Zu Deiner zweiten Farge: DPD prüft nur die Existenz und Nutzbarkeit der IKE-SA, nicht aber die der IPSec-SAs... die werden letztendlich nur durch das ICMP-Polling geprüft.... DPD wird verwendet, wenn der von der Verbindung verwendete DPD-Timeout ungleich 0 ist. Polling wird verwednet, wenn ein Eintrag in der Polling-Tabelle unter Kommunikation -> Protokolle -> Polling-Tabelle vorhanden ist.

Die Einträge in der PPP-Tabelle werden nur bei dynamic VPN ausgewertet - das macht zwar auch ein ICMP-Polling, was aber nichts mit dem unter Kommunikation -> Protokolle -> Polling-Tabelle Konfigurierbaren zu tun hat... Da dynamic VPN für IKEv2 nicht implenetiert wurde, ist die PPP-Tabelle bei IKEv2 belanglos

Gruß
Backslash

[Jirka]

Hallo Backslash,

der Poll-Eintrag wird bei einer VPN-Verbindung dann benötigt, wenn die Haltezeit 9999 ist UND die SA-Erzeugung nicht auf "Immer alle gemeinsam" oder "Gemeinsam für Keep-Alive" steht, also auf "Jede einzeln nach Bedarf"...

ahh! Dann ist die geänderte SA-Erzeugung der Grund und gar nicht das Firmwareupdate. Oha, das hatte ich schon wieder völlig vergessen, man macht ja jeden Tag zig Sachen... Denn die SA-Erzeugung hatte ich - in weiser Voraussicht, dass die Einstellung "Gemeinsam für Keep-Alive" mit der 10.20 wegfällt - schon mal umgestellt auf "Jede einzeln nach Bedarf". Und das war denn jetzt der Grund, dass die VPNs nicht mehr hochkamen. "Jede einzeln nach Bedarf" habe ich gewählt, weil es sich um Zentralen handelt, die allerdings eine VPN-Verbindung zu einer übergeordneten Zentrale haben und genau diese soll deshalb auch mit 9999 selbstständig aufgebaut werden.

Denn dann wird tatsächlich ein Datenpaket benötigt, um die SAs aufbauen zu können und das wird vom ICMP-Polling geliefert.

Das verstehe ich jetzt aber noch nicht so ganz. Wieso benötigt er ein Datenpaket, um die SAs aufbauen zu können? Schließlich kann er sie bei "Immer alle gemeinsam" auch ohne Datenpaket erzeugen/aufbauen.

Zu Deiner zweiten Frage: DPD prüft nur die Existenz und Nutzbarkeit der IKE-SA, nicht aber die der IPSec-SAs... die werden letztendlich nur durch das ICMP-Polling geprüft.... DPD wird verwendet, wenn der von der Verbindung verwendete DPD-Timeout ungleich 0 ist. Polling wird verwendet, wenn ein Eintrag in der Polling-Tabelle unter vorhanden ist.

Im VPN-Status-Trace sehe ich aber nicht mehr wie bei IKEv1 derartige Ausschriften?:

Code: Alles auswählen

[VPN-Status] 2018/12/17 15:05:37,519
VPN: poll timeout for AUGSBURG (1.2.3.4)
data received during intervall
set poll timer to 30000 ms

Die Einträge in der PPP-Tabelle werden nur bei dynamic VPN ausgewertet - das macht zwar auch ein ICMP-Polling, was aber nichts mit dem unter Kommunikation -> Protokolle -> Polling-Tabelle Konfigurierbaren zu tun hat... Da dynamic VPN für IKEv2 nicht implenetiert wurde, ist die PPP-Tabelle bei IKEv2 belanglos.

Ja, man braucht dynamic VPN ja bei IKEv2 auch nicht mehr.

Vielen Dank und viele Grüße,
Jirka

[backslash]

Hi Jirka,

"Jede einzeln nach Bedarf" habe ich gewählt, weil es sich um Zentralen handelt, die allerdings eine VPN-Verbindung zu einer übergeordneten Zentrale haben und genau diese soll deshalb auch mit 9999 selbstständig aufgebaut werden.

das ist jetzt eines der unschönen Szenarien... Hier kannst du jetzt eigentlich nur "immer alle gemeinsam" einstellen und hoffen, daß die zusäzliche Last die entsteht, weil die "Zwischen-Zentrale" auch die SAs zu ihren Filialen immer wieder oben halten will nicht zu hoch wird. Das sollte aber eigentlich kein Problem seuin, weil die Filialen ihre ersten SAs selbst aufbauen und auch bei einem Rekeying zuerst anfangen, so daß die (Zwischen-)Zentrale normalerweise nicht in die Verlegenheit kommen sollte, SAs zu den Filialen aktiv aufbauen zu wollen. Du bist aber ein willkommenes Versuchskaninchen...

Das verstehe ich jetzt aber noch nicht so ganz. Wieso benötigt er ein Datenpaket, um die SAs aufbauen zu können? Schließlich kann er sie bei "Immer alle gemeinsam" auch ohne Datenpaket erzeugen/aufbauen.

Bei "gemeinsam" wird beim Verbindungsaufbau angetriggert, daß die SAs aufgebaut werden... Bei "nach Bedarf" muß ja irgednwas da sein, das den Bedarf darstellt - und das ist eben ein Datenpaket...

Im VPN-Status-Trace sehe ich aber nicht mehr wie bei IKEv1 derartige Ausschriften?:

Code: Alles auswählen

[VPN-Status] 2018/12/17 15:05:37,519
VPN: poll timeout for AUGSBURG (1.2.3.4)
data received during intervall
set poll timer to 30000 ms

richtig. das solltest du bei IKEv2 nicht mehr sehen

Gruß
Backslash

[cpuprofi]

Hallo Backslash,

...der Poll-Eintrag wird bei einer VPN-Verbindung dann benötigt, wenn die Haltezeit 9999 ist UND die SA-Erzeugung nicht auf "Immer alle gemeinsam" oder "Gemeinsam für Keep-Alive" steht, also auf "jede einzeln nach Bedarf"...

wo ist denn dieser "Parameter" in der 10.20. geblieben?

Grüße
Cpuprofi

[Jirka]

Hallo zusammen, hallo Backslash,

in den Release-Notes zur 10.20-RC1 heißt es im Abschnitt Neues Features:

Der Schalter zur Konfiguration des Aufbaus der IPSec-SAs wurde entfernt. IPSec-SAs werden nun immer gemeinsam aufgebaut.

Demnach ist der komplette Schalter also weg. Wozu mache ich mir denn dann jetzt noch Gedanken? Und stelle was um? Das ist doch dann alles sowieso über kurz oder lang hinfällig. Aber irgendwie hatte ich den Beitrag von Backslash neulich so verstanden, dass lediglich die Einstellung "Gemeinsam für KeepAlive" entfallen ist:

die Einstellung "Gemeinsam für KeepAlive" wurde abgeschafft, weil es eigentlich keinen Sinn macht mal so und mal so zu verfahren. Insbesondere hat es immer wieder Problem mit herausgealterten SAs gegeben, weil manche IPSec-Gateways nicht damit umgehen können auch als Responder SAs bei Bedarf aufzubauen.

Eine sinnvolle Einstellung ist, den gemeinsamen Aufbau allen Filialen ein- und in der Zentrale abzuschalten. Damit ziehen die Filialen sofort alle SAs hoch und die Zentrale wird entlastet, weil sie nur noch auf einkommende Anfragen reagiert (es schadet zwar nicht, es auch in der Zentrale einzuschalten, erhöht aber deren Load unnötig)

Allerdings war mir doch so, als wenn Backslash auch schon mal geschrieben hatte, dass der Parameter eben ganz entfällt und wenn man danach sucht, dann findet man es auch (wenn auch nicht gleich, diese Forumssuche treibt einen immer in den Wahnsinn):

nein, das ist kein Bug.... Der Punkt ist entfallen... Es ist nun immer so, daß bei aktivem Verbindungsaufbau alle SAs auf einmal aufgebaut werden.

So, zurück zur letzten Antwort von Backslash:

das ist jetzt eines der unschönen Szenarien... Hier kannst du jetzt eigentlich nur "immer alle gemeinsam" einstellen und hoffen, daß die zusäzliche Last die entsteht, weil die "Zwischen-Zentrale" auch die SAs zu ihren Filialen immer wieder oben halten will nicht zu hoch wird.

Ja, aber in der 10.12 kann ich es doch noch auf "Jede einzeln nach Bedarf" lassen, das funktioniert doch auch?

Bei "nach Bedarf" muß ja irgendwas da sein, das den Bedarf darstellt - und das ist eben ein Datenpaket...

Ja, das könnte dann aber genauso ein Datenpaket aus dem lokalen LAN sein, z. B. von PRTG oder die SIP-Registrierung aus dem VCM. Das muss jetzt ja nicht zwingend ein Polling-Eintrag/-Paket sein, die Logik verstehe ich nach wie vor nicht, aber muss ich vielleicht auch nicht mehr, weil sich das Thema ja anscheinend sowieso mit der 10.20 erledigt hat. Wenn sich die Release-Notes zur 10.20 nicht wie ein Blackout-Roman lesen würden, hätte ich ja die 10.20 vielleicht auch schon mal installiert. Wobei man sagen muss, dass ja anscheinend einige heftige Probleme der letzten Monate endlich mal gefixt wurden.

richtig. das solltest du bei IKEv2 nicht mehr sehen

Ok. Aber ist das jetzt schön so? Denn man sieht ja so auch nichts vom Polling oder dem DPD, oder?

Vielen Dank und viele Grüße,
Jirka

[Dr.Einstein]

Wenn sich die Release-Notes zur 10.20 nicht wie ein Blackout-Roman lesen würden, hätte ich ja die 10.20 vielleicht auch schon mal installiert.

Wenns nicht so traurig wäre, würde ich ja glatt darüber lachen...

Gruß Dr.Einstein

[backslash]

Hi Zusammen,

im VPN bin ich nicht mehr ganz so tief drin, wie früher - ist halt nicht mehr meine Baustelle. Sorry, aber man darf hier auch mal Fehler machen... Ja, der Schalter ist komplett entfallen und es werden bei aktivem Verbindungsaufbau immer alle SAs gemeinsam hochgezogen

@Jirka

Ja, aber in der 10.12 kann ich es doch noch auf "Jede einzeln nach Bedarf" lassen, das funktioniert doch auch?

dann wirst du aber wieder die Meldung mit dem fehlenden Polling-Eintrag bekommen

Ja, das könnte dann aber genauso ein Datenpaket aus dem lokalen LAN sein, z. B. von PRTG

Dann wäre aber kein Keep-Alive (Haletzeit 9999) nötig

oder die SIP-Registrierung aus dem VCM.

nein, denn der VCM registriert sich erst, wenn die Verbindung oben ist - und dazu wird mindestens eine SA benötigt

Das muss jetzt ja nicht zwingend ein Polling-Eintrag/-Paket sein, die Logik verstehe ich nach wie vor nicht

Das Problem ist, daß für einen erfolgreichen Verbindungsaufbau eine SA benötigt wird. Steht diese nicht innerhalb von 30 Sekunden nach Start des Verbindungsaufbaus wird der Vetrbindungsaufbau mit einem Fehler "IFC-I-Connection-Timeout-IKE-IPSec" abgebrochen. Um also bein einem SA-Aufbau bei Bedarf, diese Meldung zu unterbinden, wird ein Paket benötigt - und genau das liefert das Polling. Daher wird bei Keep-Alive *UND* SA-Aufbau nach Bedarf zwingend der Pollin-Eintrag benötigt

Gruß
Backslash

[Jirka]

Hallo Backslash,

im VPN bin ich nicht mehr ganz so tief drin, wie früher - ist halt nicht mehr meine Baustelle.

oha, wusste ich gar nicht. Aber so tief, wie Du da mal drin stecktest, da kann man ja eigentlich gar nicht so recht loslassen.

Sorry, aber man darf hier auch mal Fehler machen...

Eh, natürlich! Sorry, wenn das anders rüber gekommen ist. Letztlich habe ich doch den gleichen Fehler gemacht. Ich habe im September gelesen, dass der komplette Schalter entfällt und jetzt konnte ich mich dann doch nicht mehr so genau dran erinnern und bin nach Deinem Posting ohne das zu prüfen daher nun auch davon überzeugt gewesen, dass nur ein Auswahlwert entfällt. Aber nun haben wir es ja ausdiskutiert - alles gut.

Ja, der Schalter ist komplett entfallen und es werden bei aktivem Verbindungsaufbau immer alle SAs gemeinsam hochgezogen

Nur noch mal zur Klarstellung: Und wenn kein aktiver Verbindungsaufbau stattfindet, dann nicht?

dann wirst du aber wieder die Meldung mit dem fehlenden Polling-Eintrag bekommen

Na ja, nun ja nicht mehr, nun ist da ja ein Eintrag in der Polling-Tabelle drin...

So, wo wir jetzt schon etwas beim IKEv2 hier waren, zumindest am Anfang, ich hätte da noch eine Frage, die allerdings vermutlich nicht mehr vor Weihnachten zu klären ist, aber die mir schon seit über einem halben Jahr hier zu schaffen macht:
Ich habe hier einen LANCOM mit VCM (derzeit 10.12.0601, wie oben geschrieben) und einer SIP-Leitung, die sich über eine IKEv2-VPN auf der anderen Seite registriert. Das funktioniert soweit sehr gut. Problem: Sobald der Upload ausgelastet ist, z. B. nur mit einem einfachen Upload von Dateien auf einen FTP-Server, registriert sich die Leitung nicht mehr. Dauert der Upload eine halbe Stunde, so kann eine halbe Stunde nicht mehr telefoniert werden. Alle anderen SIP-Leitungen (WAN, früher auch eine über IKEv1) sind registriert. Nur nicht die über die IKEv2-Verbindung. Da der Provider (also über normales WAN) für SIP-DSCP AF-31 verwendet, ist das so auch im VCM eingestellt. Firewall-Regeln, die irgendwelchen Traffic jetzt bevorzugen würden, gibt es nicht. Frage logischerweise: Wie kann das sein? Oder besser: Was könnte die Ursache dafür sein? Oder noch besser: Was könnte ich jetzt tun, um dem mal auf den Grund zu gehen? Ich bin der Meinung, dass das an IKEv2 liegt und das Problem bei IKEv1 nicht auftritt, aber ich habe leider bisher keine Zeit gehabt, das zu verifizieren. Ach ja, die Bandbreite von DSL-1 ist exakt angegeben und das gibt die Leitung auch her, normale Telefonate über die SIP-Leitungen zum Provider zum Zeitpunkt des FTP-Uploads sind ja auch kein Problem.

Vielen Dank und viele Grüße,
Jirka

[backslash]

Hi Jirka,

Nur noch mal zur Klarstellung: Und wenn kein aktiver Verbindungsaufbau stattfindet, dann nicht?

dann sollte ja die andere Seite die SAs aufbauen. Wenn sie es nicht macht, werden SAs halt bei Bedarf aufgebaut (so hab ich das zumindest verstanden)

zu deinem SIP Poroblem kann ich leider erstmal nichts sagen. Das klingt für mich aber trotzdem so, als ob der Upload die komplette Bandbriete frißt und die "hin und wieder" mal vorbeikommenden SIP-Pakete entweder irgendwo verworfen werden oder zu lange unterwegs sind. Nutzt du ein externes Modem oder das eingebaute?

Gruß
Backslash

[Jirka]

Hallo Backslash,

zu deinem SIP Poroblem kann ich leider erstmal nichts sagen.

ja, schade. Auch keine Idee, was ich jetzt tun/schauen/machen könnte?

Das klingt für mich aber trotzdem so, als ob der Upload die komplette Bandbriete frißt und die "hin und wieder" mal vorbeikommenden SIP-Pakete entweder irgendwo verworfen werden

Ja, nur die zur WAN-Seite hin werden nicht verworfen?! Nur die SIP-Pakete, die über die IKEv2-Verbindung gehen? Man könnte mal schauen, ob das DSCP sauber in den Header vom IPsec-Packet übertragen wird. Oder ich stelle mal auf IKEv1 um. Was soll ich machen? (Heute und morgen schaffe ich es aber vermutlich nicht mehr.)

Nutzt du ein externes Modem oder das eingebaute?

CPE von der Telekom am CompanyConnect oder Kabelmodem bei mir. Soll ich mal den Upload in DSL-x halbieren? Aber das wird auch nichts ändern. Hier ist irgendwo ein Problem, ich weiß nur noch nicht, wie ich es untersuchen soll.

Vielen Dank und viele Grüße,
Jirka

[backslash]

Hi Jirka,

Ja, nur die zur WAN-Seite hin werden nicht verworfen?! Nur die SIP-Pakete, die über die IKEv2-Verbindung gehen? Man könnte mal schauen, ob das DSCP sauber in den Header vom IPsec-Packet übertragen wird. Oder ich stelle mal auf IKEv1 um. Was soll ich machen?

Da kannst natürlich alles der Reihe nach mal ausprobieren, um das Problem genauer einzugrenzen - müßtest das danach allerding auch offiziell beim Support einkippen, denn gerade zusammen mit dem VCM kann ich dir überhaupt nicht weiterhelfen - ich wüßte nichtmal wie ich den Bugeitrag formulieren solle...

(Heute und morgen schaffe ich es aber vermutlich nicht mehr.)

Das Jahr nähert sich mit riesen Schritten seinem Ende... das wird hier sowieso dieses Jaher eher nichts mehr...

CPE von der Telekom am CompanyConnect oder Kabelmodem bei mir. Soll ich mal den Upload in DSL-x halbieren?

es wäre mal einen Versuch wert, denn dann siehst du, ob das Paket im LANCOM oder im Telekom-Router/Kabelmodem verlorengeht.

Aber das wird auch nichts ändern.

Wenn es danach funktioniert, könnte man klar sagen, daß das Problem nicht im LANCOM liegt. Und wenn es immer noch nicht funktioniert, dann liegt das Problem wohl doch am LANCOM... Beides wäre schon eine Änderung zum jetzigen Zustand, in dem rein gar nichts zu dem Problem gesagt werden kann (außer daß es auftrítt...)

Gruß
Backslash