17
Abbrüche bei IPSEC IKEv2
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1666446913
Url: https://administrator.de/contentid/1666446913
Ausgedruckt am: 24.11.2024 um 17:11 Uhr
17 Kommentare
Neuester Kommentar
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.
1
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.
2
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
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
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!
1Zitat von @149569:
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!
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!
1
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
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
Wenn's das denn war bitte den Thread dann auch als erledigt markieren !
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
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
Habt ihr noch Ideen?
Danke.
Tak
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:
13.01.2022 12:11:16 IPSec (charon) 09[CFG]<6670> looking for an IKEv2 config for 84.177.139.253...46.81.230.28
13.01.2022 12:11:16 IPSec (charon) 09[IKE]<6670> no IKE config found for 84.177.139.253...46.81.230.28, sending NO_PROPOSAL_CHOSEN Bintec Seite:
12:10:45 INFO/IPSEC: Destroy Bundle 101 (Peer 1 Traffic -2)
12:10:45 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 0 (-): blocked for 30 seconds
12:10:45 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 5112 (I): delete ip 46.81.230.28 -> ip 84.177.139.253: Blocked
12:11:15 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 0 (-): reactivated 12:11:15 DEBUG/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 0 (-): Automatic dialup 12:11:15 INFO/IPSEC: CHILD_SA: peer 1 (BT Rewe --> LA) traf 0 bundle 102 (I): created 0.0.0.0/0:0 < any > 0.0.0.0/0:0 rekeyed 0
12:11:15 DEBUG/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 5113 (I): identified ip 46.81.230.28 -> ip 84.177.139.253
12:11:15 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 5113 (I): failed id No Id -> ip 84.177.139.253 (NO_PROP)
12:11:15 INFO/IPSEC: CHILD_SA: peer 1 (BT Rewe --> LA) bundle 102 (I): deleted (15), Pkts: 0/0 Hb: 0/0 Bytes: 0(0)/0(0) rekeyed by 0
12:11:15 INFO/IPSEC: Destroy Bundle 102 (Peer 1 Traffic -2)
12:11:15 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 0 (-): blocked for 30 seconds
12:11:15 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 5113 (I): delete ip 46.81.230.28 -> ip 84.177.139.253: Blocked 12:11:45 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 0 (-): reactivated
12:11:45 DEBUG/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 0 (-): Automatic dialup 12:11:45 INFO/IPSEC: CHILD_SA: peer 1 (BT Rewe --> LA) traf 0 bundle 103 (I): created 0.0.0.0/0:0 < any > 0.0.0.0/0:0 rekeyed 0
12:11:46 DEBUG/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 5114 (I): identified ip 46.81.230.28 -> ip 84.177.139.253 12:11:46 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 5114 (I): failed id No Id -> ip 84.177.139.253 (NO_PROP) 12:11:46 INFO/IPSEC: CHILD_SA: peer 1 (BT Rewe --> LA) bundle 103 (I): deleted (15), Pkts: 0/0 Hb: 0/0 Bytes: 0(0)/0(0) rekeyed by 0 12:11:46 INFO/IPSEC: Destroy Bundle 103 (Peer 1 Traffic -2)
12:11:46 INFO/IPSEC: IKE_SA: peer 1 (BT Rewe --> LA) sa 0 (-): blocked for 30 seconds 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
Habt ihr noch Ideen?
Danke.
Tak
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.
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.
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
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 ) Kann natürlich sein dass die Bintecs untereinander ganz anders reagieren und sich verständigen
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
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
) Kann natürlich sein dass die Bintecs untereinander ganz anders reagieren und sich verständigenAlso 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 ?!
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
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
UTM Phase 1
Bintec Phase 2
UTM Phase 2
VG Tak
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
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
Bintec Phase 2
VG Tak
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.
Ansonsten würde ich empfehlen zumindest eine feste IP für den Hauptstandort zu beantragen.
2
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.
Danke für den Hinweis
Tak
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.
Danke für den Hinweis
Tak
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.
1
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
Ich danke euch jedenfalls allen für den Input.
Schönen Sonntag noch!
Tak
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
Ich danke euch jedenfalls allen für den Input.
Schönen Sonntag noch!
Tak
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... 
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 !
Case closed...
