9
IPSec mit IKEv2 von Bintec zu Cisco - Cookie-Problematik?
Verwendete Geräte:
Meine Seite = Bintec RS353jwv Version V.10.2.12.100 IPv6, IPSec from 2022/08/25
Gegenseite = Cisco FTD 2120
Verbindungsaufbau vom Bintec (ausgehend) zum Cisco schlägt fehl. Ich vermute einen Zusammenhang mit dem von Cisco gesendeten Cookie.
Logauszug Cisco:
Logauszug Bintec:
Laut Aussage des Cisco-Admins wird dessen öffentliche IP als ID gesendet. Die Cookie-Nutzung kann/will er nicht deaktivieren, da dies für nur global für sämtliche Verbindungen ginge.
Hat schonmal jemand diese Konstellation erfolgreich aktivieren können? Verbindungsaufbau vom Cisco zum Bintec klappt übrigens, d. h. die Einstellungen passen grundsätzlich. Das VPN soll aber nur on demand vom Bintec aufgebaut werden, daher hilft es andersrum leider nicht.
Vielen Dank für Rückmeldungen.
Meine Seite = Bintec RS353jwv Version V.10.2.12.100 IPv6, IPSec from 2022/08/25
Gegenseite = Cisco FTD 2120
Verbindungsaufbau vom Bintec (ausgehend) zum Cisco schlägt fehl. Ich vermute einen Zusammenhang mit dem von Cisco gesendeten Cookie.
Logauszug Cisco:
Local:45.x.x.x:500 Remote:80.x.x.x:795 Username:Unknown IKEv2 Received a IKE_INIT_SA request
Local:45.x.x.x:500 Remote:80.x.x.x:795 Username:Unknown IKEv2 Sending COOKIE challenge to throttle possible DoS
Local:45.x.x.x:500 Remote:80.x.x.x:795 Username:Unknown IKEv2 Negotiation aborted due to ERRORLogauszug Bintec:
IPSEC: CHILD_SA: peer 23 (Name) traf 0 bundle -352 (I): created 10.234.x.x/24:0 < any > 10.102.x.x/32:0 rekeyed 0
IPSEC: IKE_SA: peer 23 (Name) sa 304 (I): identified ip 80.x.x.x -> ip 45.x.x.x
IPSEC: IKE_SA: peer 23 (Name) sa 304 (I): failed id No Id -> ip 45.x.x.x (COOKIE)
IPSEC: CHILD_SA: peer 23 (Name) bundle -352 (I): deleted (15), Pkts: 0/0 Hb: 0/0 Bytes: 0(0)/0(0) rekeyed by 0 Laut Aussage des Cisco-Admins wird dessen öffentliche IP als ID gesendet. Die Cookie-Nutzung kann/will er nicht deaktivieren, da dies für nur global für sämtliche Verbindungen ginge.
Hat schonmal jemand diese Konstellation erfolgreich aktivieren können? Verbindungsaufbau vom Cisco zum Bintec klappt übrigens, d. h. die Einstellungen passen grundsätzlich. Das VPN soll aber nur on demand vom Bintec aufgebaut werden, daher hilft es andersrum leider nicht.
Vielen Dank für Rückmeldungen.
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: 3924266470
Url: https://administrator.de/forum/ipsec-mit-ikev2-von-bintec-zu-cisco-cookie-problematik-3924266470.html
Ausgedruckt am: 23.12.2024 um 04:12 Uhr
9 Kommentare
Neuester Kommentar
Moin erstmal, so viel Zeit sollte sein.
Die Frage ist, warum hat der Bintec so viele halb offene SAs mit dem Responder, das dieser den COOKIE Mechanismus aktiviert? Stimmen die Lifetime's nicht mit der Gegenseite überein? Stimmen die gegenseitigen Identities?
Der COOKIE-Mechanismus ist ja Teil der IKEv2 RFC (rfc5996, würde der Bintec das nicht unterstützen wäre IKEv2 dort fehlerhaft implementiert(gehe ich zwar nicht von aus, aber bei bintec kann dir so gut wie alles passieren).
Cheers
certguy
Die Frage ist, warum hat der Bintec so viele halb offene SAs mit dem Responder, das dieser den COOKIE Mechanismus aktiviert? Stimmen die Lifetime's nicht mit der Gegenseite überein? Stimmen die gegenseitigen Identities?
Der COOKIE-Mechanismus ist ja Teil der IKEv2 RFC (rfc5996, würde der Bintec das nicht unterstützen wäre IKEv2 dort fehlerhaft implementiert(gehe ich zwar nicht von aus, aber bei bintec kann dir so gut wie alles passieren).
Cheers
certguy
Nutzt der Bintec auch eine feste IPv4 IP oder hat der eine dynamische?
Was passiert wenn der Cisco für diesen Peer rein nur als Responder definiert wird mit address 0.0.0.0 0.0.0.0 ?? In dem Fall sollte er alles annehmen was reinkommt sofern der PSK stimmt.
Siehe dazu auch hier.
Was passiert wenn der Cisco für diesen Peer rein nur als Responder definiert wird mit address 0.0.0.0 0.0.0.0 ?? In dem Fall sollte er alles annehmen was reinkommt sofern der PSK stimmt.
Siehe dazu auch hier.
1
Hallo,
vielleicht als Tip. Die Dokumentation bei Bintec (manuals) enthalten oft keine aktuellen Informationen zur Firmware. Es loht sich bei denen, die Release-Notes der Firmware-Versionen zu studieren (und zwar alle der Reihe nach
). Dort sind oft Details genauer beschrieben. Aktuell ist die bintec-Seite etwas unübersichtlich.
https://archive.bintec-elmeg.com/?dir=Files/Router/bintec_RSxx3_Series/c ...
In den aktuellen Firmware-Release-note stehen z.B. etliche Details zur IKEv2.
Grüße
lcer
vielleicht als Tip. Die Dokumentation bei Bintec (manuals) enthalten oft keine aktuellen Informationen zur Firmware. Es loht sich bei denen, die Release-Notes der Firmware-Versionen zu studieren (und zwar alle der Reihe nach
). Dort sind oft Details genauer beschrieben. Aktuell ist die bintec-Seite etwas unübersichtlich.https://archive.bintec-elmeg.com/?dir=Files/Router/bintec_RSxx3_Series/c ...
In den aktuellen Firmware-Release-note stehen z.B. etliche Details zur IKEv2.
Grüße
lcer
Zitat von @3803037559:
Die Frage ist, warum hat der Bintec so viele halb offene SAs mit dem Responder, das dieser den COOKIE Mechanismus aktiviert? Stimmen die Lifetime's nicht mit der Gegenseite überein? Stimmen die gegenseitigen Identities?
Der COOKIE-Mechanismus ist ja Teil der IKEv2 RFC (rfc5996, würde der Bintec das nicht unterstützen wäre IKEv2 dort fehlerhaft implementiert(gehe ich zwar nicht von aus, aber bei bintec kann dir so gut wie alles passieren).
Die Frage ist, warum hat der Bintec so viele halb offene SAs mit dem Responder, das dieser den COOKIE Mechanismus aktiviert? Stimmen die Lifetime's nicht mit der Gegenseite überein? Stimmen die gegenseitigen Identities?
Der COOKIE-Mechanismus ist ja Teil der IKEv2 RFC (rfc5996, würde der Bintec das nicht unterstützen wäre IKEv2 dort fehlerhaft implementiert(gehe ich zwar nicht von aus, aber bei bintec kann dir so gut wie alles passieren).
Der Cookie-Krams ist auf dem Cisco wohl generell aktiv. Die Meldung kam bereits beim allerersten Request-Versuch.
Ich vermute, dass das Cookie inkompatibel ist zu dem, was der Bintec verarbeiten kann.
Gruß, Christian
Zitat von @aqui:
Nutzt der Bintec auch eine feste IPv4 IP oder hat der eine dynamische?
Was passiert wenn der Cisco für diesen Peer rein nur als Responder definiert wird mit address 0.0.0.0 0.0.0.0 ?? In dem Fall sollte er alles annehmen was reinkommt sofern der PSK stimmt.
Siehe dazu auch hier.
Nutzt der Bintec auch eine feste IPv4 IP oder hat der eine dynamische?
Was passiert wenn der Cisco für diesen Peer rein nur als Responder definiert wird mit address 0.0.0.0 0.0.0.0 ?? In dem Fall sollte er alles annehmen was reinkommt sofern der PSK stimmt.
Siehe dazu auch hier.
Beide Seiten haben feste IPs. Das mit 0.0.0.0 werde ich mal vorschlagen. Danke für die Anregung.
Gruß,
Christian
Nicht nur da, strongswan (charon) welches die überwiegend genutzte Implementierung ist, hat das ebenfalls per Default aktiv (cookie_threshold = 30 / cookie_threshold_ip = 3). Das eigentlich fast überall Standard bei IKEv2.
Ich vermute, dass das Cookie inkompatibel ist zu dem, was der Bintec verarbeiten kann.
Eher nicht, ist eigentlich absoluter Standard s. RFC.Ich vermute, dass das Cookie inkompatibel ist zu dem, was der Bintec verarbeiten kann.
Nein, denn IKEv2 ist ein RFC Standard an den sich weltweit alle halten müssen. Kollege @3803037559 hat es schon gesagt. Der Charon Daemon ist fast überall implementiert.Wenn der Cisco als reiner Responder konfiguriert ist sind im Cookies oder keine auch egal da das dynamisch ausgehandelt wird. Ggf. ist es besser den Peer auf FQDN Authentisierung umzustellen, das ist generell bei unterschiedlichen Herstellern toleranter als die IP.
Hat sich erstmal erledigt, aktuell wird der Tunnel aufgebaut. Ich weiß leider nicht, woran es gelegen hat und hoffe, dass das so bleibt Jetzt muss ich nur noch das Tunnel-NAT aktiviert bekommen, das will noch nicht so, wie es soll. Aber dafür mache ich lieber einen neuen Thread auf.
Danke & Gruß, Christian
Jetzt muss ich nur noch das Tunnel-NAT aktiviert bekommen, das will noch nicht so, wie es soll. Aber dafür mache ich lieber einen neuen Thread auf.Danke & Gruß, Christian
1Jetzt muss ich nur noch das Tunnel-NAT aktiviert bekommen
Normalerweise Unsinn in lokalen VPNs. Sowas sollte man niemals machen wenn es nicht unbedingt sein muss. Vermutlich supportet der Bintec sowas auch gar nicht, denn wenn Source und Destination NAT musst du das immer beidseitig machen. Bei IPsec ist das oft nur mit VTI Interfaces möglich was der Bintec de facto nicht kann. Der Cisco schon.Ändere lieber die IP Netze das ist die deutlich bessere Lösung!
