Abbrüche bei IPSEC IKEv2

takvorian
Goto Top
Hallo zusammen,

ich versuch mal mein Glück bei euch, wenns schon bei den beiden Herstellen nicht so recht klappen will:

Ausgangslage Kunde: 1x Bintec RS353 in der Zentrale und 20x Bintec Be.IP Plus in den Filialen
Standorte sind alle mit VPN IPSEC IKEv2 Tunneln verbunden, Abbrüche gab es keine nennenswerten.
Kein einziger Standort verfügt über eine feste IP Adresse, alles DynDNS über Securepoint.
Alle Router sind direkt am DSL angeschlossen und vor deb RS353 (neu UTM) ist ein Draytec Modem

Situation vor kurzem: Kunde kommt her und sagt..komm ihr seid doch Securepoint Partner und ich will endlich mal ne echte Firewall.
Also dem Kunden eine RC200 von Securepoint hingestellt, die IPSEC Tunnel konfiguriert und losgelegt.

Leider kommt es seit dem Einbau der Firewall immer wieder mal zu Abbrüchen des IPSEC Tunnels so dass zwischen zentrale udn Filiale keine Verbindung mehr zustande kommt. Ich initialisiere dann meist den Tunnel auf der UTM neu und die Verbindung baut sich neu auf.

Das ganze habe ich dann als Ticket an Securepoint als auch Bintec (wobei ich letztere ausschliessen möchte) weitergegeben, incl. Logfiles und als Antwort bekam ich nur lapidar dass es wohl an den Phasen liegen müsse. Ich habe die UTM und die Be.IP dann dahingehend angepasst dass ich den Tunnel von der UTM aus aufbauen lasse und auch für jedes Subnetz in Phasese 2 ein eigener Aufbau getätigt wird (strict). Brachte nicht wirklich einen Erfolg. Wobei meiner Meinung nach "strict" eh nur bei IKEv1 sinnvoll ist.

Ich schreib hier mal kurz zusammen wie die einzelnen Phasen aufgebaut sind, welche lifetimes usw. Vielleicht habt ja ihr eine Idee was noch anders zu konfigurieren wäre.
Mein Ziel wäre es, an allen Standorten eine UTM von Securepointhinzustellen und dann auf SSL-VPN Tunnel zu setzen. Das läuft abslolut stabil, nur kann Bintec kein SSL VPN.


Phase1: (IKEv2)
Verschlüsselung: AES-256
Authentifizierung: SHA2 256
DH Gruppe: 14 (2048Bit)
Lifetime: 14400 Sekunden
Schlüssel erneut erstellen nach 80% Lebensdauer
Alive Chekc: enabled
NAT-Traversal: enabled

Phase 2: (IPSEC)
Verschlüsselung: AES-256
Authentifizierung: SHA2 256
DH Gruppe: 14 (2048Bit)
Lifetime: 7200 Sekunden
Schlüssel erneut erstellen nach 80% Lebensdauer
IP Komprimierung: false
Alive Chek: auto
PMTU: aktiviert

Peer Parameter
Peer Adresse und Peer ID: DynDNS Adresse der Zentrale
IKE VErsion: IKEv2
Authentifizierungsmethode: PSK
lokaler ID Typ: FQDN
Lokale ID: DynDNS Adresse der Filiale

Analog das gleiche dann auf der UTM in der Zentrale.
Bei den Lifetimes bin ich mir nicht wirklich sicher ob diese Zeiten so in Ordnung sind, Phase 2 ist ja kürzer als Phase 1...Aber ob die lange genug bez. zu kurz sind kann ich jetzt nicht wirklich sagen. Rekeying dürfte ja nur dann zutreffen wenn die Liefetime abläuft.

Habt Ihr Ideen oder Ratschläge was ich am Tunnelaufbau noch verbessern könnte?

Vielen Dank für Euer Feedback.

VG Tak

Content-Key: 1666446913

Url: https://administrator.de/contentid/1666446913

Ausgedruckt am: 09.08.2022 um 19:08 Uhr

Mitglied: aqui
Lösung aqui 28.12.2021 aktualisiert um 16:24:26 Uhr
Goto Top
Leider kommt es seit dem Einbau der Firewall immer wieder mal zu Abbrüchen des IPSEC Tunnels
Da fehlt im Thread leider das Wichtigste:
WAS steht in dem Falle in den Logs der beiden beteiligten Endgeräte ?! Kollege @149569 hat diesen wichtigen Punkt ja unten auch schon betont.
Das sollte ja zumindestens einen groben Anhaltspunkt für die Ursache geben.
Wie unten auch schon genannt sollten die Filialen in einem verzögerten DynDNS Umfeld immer die Inititiators sein und die Zentrale nur der Responder, sprich also diese festgelegte Rollen haben.
Mitglied: 149569
149569 28.12.2021 aktualisiert um 16:21:10 Uhr
Goto Top
Was sagen denn die Detail-Logs auf beiden Seiten?! Immer wieder gerne kommt es via DynDNS angebundenen Standorten zu dem Problem der DNS-Auflösung das bei einer Zwangstrennung und noch nicht vollzogenem DNS-Update der Server den FQDN zur falschen IP auflöst und dann die Phase1 der Identity-Abgleich natürlich nicht mehr stimmt. Ich arbeite bei solchen Standorten bei den Identities inzwischen auch lieber mit Zertifikaten das ist diesbezüglich robuster und funktioniert dann auch bei DSLite angebundenen Filialen zuverlässig.
Mitglied: Spirit-of-Eli
Spirit-of-Eli 29.12.2021 um 00:47:18 Uhr
Goto Top
Moin,

es wurde schon vieles gesagt aber zwei Punkte möchte ich ergänzen.

1. wieso ist die life time unterschiedlich?
2. DPD würde ich immer explizit einschalten.

Gruß
Spirit
Mitglied: 149569
149569 29.12.2021 aktualisiert um 07:52:19 Uhr
Goto Top
Zitat von @Spirit-of-Eli:
1. wieso ist die life time unterschiedlich?
Zwischen Phase1 und den P2 SAs ist eine unterschiedliche Lifetime die Regel, wichtig ist nur das die Lifetimes für Phase1 und 2 am Peer identisch eingetragen werden!
Mitglied: Spirit-of-Eli
Spirit-of-Eli 29.12.2021 um 10:06:57 Uhr
Goto Top
Zitat von @149569:

Zitat von @Spirit-of-Eli:
1. wieso ist die life time unterschiedlich?
Zwischen Phase1 und den P2 SAs ist eine unterschiedliche Lifetime die Regel, wichtig ist nur das die Lifetimes für Phase1 und 2 am Peer identisch eingetragen werden!

Wenn dem so ist, habe ich wieder was gelernt.
ich habe bisher immer den selben Wert eingetragen und nur Probleme gehabt wenn "dead peer detection" nicht auf beiden Seiten aktiv gewesen ist.

##Habe hier einen Artikel zu Meraki gefunden wo deine Aussage gut beschrieben ist:
https://documentation.meraki.com/MX/Site-to-site_VPN/IPsec_VPN_Lifetimes

Danke!
Mitglied: takvorian
takvorian 30.12.2021 um 08:52:48 Uhr
Goto Top
Guten Morgen zusammen,

danke für eure Tipps. DPD muss ich prüfen ob auf beiden Seiten aktiv. Wenn das Problem wieder mal auftritt checke ich die Logfiles.
Auf der Bintec war das glaub ich debug ipsec& bekomm ich hin.
Zentrale wird auf statische IP Adresse umgestellt und ich lassen die Filialen die Verbindung aufbauen.
Dann schau ich weiter.

Jetzt aber nen guten Rutsch an alle.

VG Takvorian
Mitglied: aqui
aqui 30.12.2021 um 11:16:49 Uhr
Goto Top
Wenn's das denn war bitte den Thread dann auch als erledigt markieren !
https://administrator.de/faq/32
Mitglied: takvorian
takvorian 13.01.2022 aktualisiert um 12:53:18 Uhr
Goto Top
Hallo zusammen,

ich nehme das Tehma heute nochmal auf. Heute bin ich auch dazu gekommen mal zu schauen was auf beiden Seiten passiert. Umgestellt habe ich es wie empfohlen dass die Filialseite die Verbindung aufbaut.

aktuell ist es erneut so dass ein Tunnel von der Filialseite aus, nicht wieder aufgebaut werden.

Securepoint Seite:

Bintec Seite:


Die Meldung "no Proposal choosen" ist verwirrend, da die Tunnel sich ja manuell wieder aufbauen lassen (initialisierung auf der SP Seite) und dann die Tunnel wieder Tagelang funktionieren.

IP Adressen lasse ich bewusst unmaskiert, sind eh alle dynamisch face-smile

Habt ihr noch Ideen?

Danke.

Tak
Mitglied: aqui
Lösung aqui 13.01.2022 aktualisiert um 13:22:31 Uhr
Goto Top
Wie sieht das mit den P1 und P2 Lifetime Zeiten und den DPD Keepalives aus ?? Hast du die beidseitig entsprechend auf die gleichen Werte angepasst ?
Bedenke auch das der Tunnel immer nur aufgebaut wird wenn relevanter Traffic dafür vorliegt wie in der P2 definiert. Du solltest also immer mal einen Ping laufen lassen um den Tunnel zu triggern. Alternativ kannst du auf der pfSense einen Keepalive Ping laufen lassen auf den Bintec.
Hab leider keinen Bintec zum Testen aber in einem zu deinem identischen Vergleichs Setup mit je einem Cisco IOS, Meraki, Mikrotik, StrongSwan, OPNsense, FritzBox (alle mit angepassten Lifetime und DPD Werten !) lies sich dein beobachtetes Verhalten nicht reproduzieren.
Mitglied: takvorian
takvorian 13.01.2022 aktualisiert um 14:04:22 Uhr
Goto Top
Hallo aqui,

vielen Dank für Deinen Einwand.
BEIDE Seiten sind Identisch sowohl was Lifetimes als auch Verschlüsselung betrifft. Eingestellt wie im ersten Posting von mir.
Beim Bintec gibt es mehr Möglichkeiten als bei Securepoint, jedoch erinnere ich mich dunkel daran dass hier entweder / oder gilt. Also Entweder Lebensdauer in Sekunden ODER 80% der Lifetime
p1

Grüße dalass

Nachtrag: Ich werde von der Zentrale aus einrichten, dass regelmässig ein Keepalive ping an die Bintec Router gesandt wird.
Seltsamerweise, wenn ich die UTM wieder gegen den alten Bintec tausche, steht der Tunnel durchgehend ohne einen einzigen Abbruch (Ausnahme Zwangstrennung Internet- Stromausfall face-smile ) Kann natürlich sein dass die Bintecs untereinander ganz anders reagieren und sich verständigen
Mitglied: aqui
aqui 13.01.2022 um 19:31:03 Uhr
Goto Top
Also Entweder Lebensdauer in Sekunden
Sekunden sind die übliche Angabe. Was aber fehlt ist die Angabe ob es die Phase 1 oder Phase 2 ist. Normal hast du immer 2 Lifetimes für die P1 und P2 (siehe pfSense Setup !)
wenn ich die UTM wieder gegen den alten Bintec tausche
Ggf. Fehler im Regelset ? Für IPsec musst du UDP 500, UDP 4500 und das ESP Protokoll (IP Nr. 50) freigeben ?!
Mitglied: takvorian
takvorian 13.01.2022 aktualisiert um 20:42:41 Uhr
Goto Top
Hallo aqui,

danke für deine späte (von der Uhrzeit her) Antwort.

Wenn ein Fehler im Regelset vorläge, also fehlende Freigaben, dann dürfte der Tunnel nicht aufgebaut werden. Hier kann ich Fehler zu 100% ausschließen.
Die Tunnel stehen ja manchmal tagelang und plötzlich ist dann ein Tunnel tot. UTM meldet "no IKE config forund" Siehe LogAuszug weiter oben.
Gerne anbei beiden Lifetimes und Verschlüsselungen vom Bintec und der UTM.
Der Punkt "STRICT" bei der Phase 1 dürfte doch irrelevant sein, den mMn gilt Strict nur bei IKEv1

Alle Tunnel werden mit IKEv2 aufgebaut, was ja angeblich nicht so störanfällig ist, ausser mal bei mir face-smile
Ach ja nochwas. Ich hatte heute mit PingInfoView dann einen Keepalive Ping auf die lokalen IP Adressen der Bintecs eingerichtet ( 1 Ping alle 30 Sekunden ) Trotzdem ist ein Tunnel so gegen 17.30 abgebrochen.

Bintec Phase 1
phase1
UTM Phase 1
phase1_utm

Bintec Phase 2
phase2
UTM Phase 2
phase2_utm

VG Tak
Mitglied: 149569
149569 13.01.2022 aktualisiert um 23:41:22 Uhr
Goto Top
Ich tippe ja immer noch auf die korrekte gegenseitige Auflösung der Hostnamen zu den IPs untereinander. Ich würde die Authentifizierung mal statt auf den FQDN zu legen diese auf eine feste Key-ID für Standort und Filiale festsetzen wenn das bei den Teilen möglich ist. Sowas bekomme ich nämlich selbst mit ner Fritte in einer Custom-Config hin, was bei DSLITE-Opfern ja oft die einzige Möglichkeit bei IPSec ist.
Ansonsten würde ich empfehlen zumindest eine feste IP für den Hauptstandort zu beantragen.
Mitglied: takvorian
takvorian 14.01.2022 aktualisiert um 06:23:22 Uhr
Goto Top
Hallo Hacktor,

im Falle des gestrigen Ausfalles habe ich die Auflösung der Hostnamen zu den IP's auf beiden Seiten geprüft gehabt. Da hatte alles gepasst.
Schlüssel ID sollte sich festlegen lassen. Wenn ich dazu komme teste ich das heute.

paarparameter
utmph1-allgemein

Danke für den Hinweis

Tak
Mitglied: aqui
aqui 14.01.2022 um 10:17:14 Uhr
Goto Top
UTM meldet "no IKE config forund"
Das ist aber dann ein Bug wenn diese IKE Konfig de facto vorhanden ist. Oder...wie der Kollege @149569 oben schon sagt ein Versagen der FQDN Auflösung. Daran hängt ja dann auch wieder die "IKE config". Bei DynDNS Hostnamen ist das immer so eine Sache...
Den Test mit dem Key IDs solltest du also in jedem Falle einmal machen.
Mitglied: takvorian
takvorian 30.01.2022 um 12:34:19 Uhr
Goto Top
Hallo zusammen,

hat bissi gedauert bis ich mich wieder gemeldet hab, das Problem scheint aktuell im Griff zu sein.
Leider hab ich das mit den KeyID's nicht hinbekommen dass sich ein Tunnel aufgebaut hat.

Zum Erfolg hatte schlussendlich geführt dass ich die Tunnel von beiden Seiten aus aufbauen lassen (das geht ja bei IPSEC). Weiterhin habe ich auf den BINTEC die Tunnelblockzeit auf 0 gesetzt sowie, und ich denke das war der Knackpunkt, NAT-Traversal deaktiviert, denn die Router bauen ja alle die Verbindung selbst auf.
Seit diese Einstellungen aktiv sind, habe ich keine Klagen mehrgehört und das schon seit 10 Tagen face-smile

Ich danke euch jedenfalls allen für den Input.

Schönen Sonntag noch!

Tak
Mitglied: aqui
aqui 30.01.2022 um 13:33:23 Uhr
Goto Top
Leider hab ich das mit den KeyID's nicht hinbekommen dass sich ein Tunnel aufgebaut hat.
Woran lags ?? Was war dier Fehler ? Sollte immer fehlerfrei klappen. Eine Beispiel kannst du einmal hier sehen zwischen unterschiedlichen Komponenten.
von beiden Seiten aus aufbauen lassen (das geht ja bei IPSEC).
Und ist ja der übliche Standard... face-wink
den BINTEC die Tunnelblockzeit auf 0 gesetzt
Wer oder was ist eine "Tunnelblockzeit" bei IPsec ??? Nie gehört....
NAT-Traversal deaktiviert,
Uuuhhhh... sowas ist sehr unüblich, denn du kannst d aniemals wissen ob irgendwo ein NAT Gateway (DS-Lite, CGN etc.) im Pfade ist. Das kann also gefährlich werden weil du auf Providertechnik keinerlei Einfluss hast. NAT-T ist immer automatisch, Sprich IPsec discovered das automatisch selber und nutzt es oder nutzt es nicht wenn es NAT-T im Pfad erkennt. Diese Automatik sollte man imemr belassen.
Aber was solls....wenns nun rennt beweist ja das den Erfolg ! face-wink
Case closed...