1
German - Deutsch / Falsche ID in Phase 1 bei redundanten IPSec-Verbindungen
« on: September 14, 2023, 02:52:59 pm »
Hallo zusammen,
die IPSec-Verbindungen funktionieren eigentlich wie gewollt.
Nur wenn man redundante Leitungen hinzufügt, kommt OPNsense wohl mit den IDs durcheinander?
Ist die Vorgehensweise wie im Screenshot gezeigt korrekt?
Lokale Seite hat 2 Internetleitungen und die entfernte Seite hat 2 Internetleitungen, also Redundanz auf beiden Seiten.
Ich gehe davon aus, dass die Rounds nacheinander abgearbeitet werden, also wenn Round 0 fehlschlägt, wird Round 1 durchfgeführt usw., oder sehe ich das falsch?
Die Gegenseite ist eine Sophos UTM, dessen Internetleitung 1 ist übrigens gerade tot, Bagger an Glasfaser .
Hier ist der Log von der OPNsense:
die IPSec-Verbindungen funktionieren eigentlich wie gewollt.
Nur wenn man redundante Leitungen hinzufügt, kommt OPNsense wohl mit den IDs durcheinander?
Ist die Vorgehensweise wie im Screenshot gezeigt korrekt?
Lokale Seite hat 2 Internetleitungen und die entfernte Seite hat 2 Internetleitungen, also Redundanz auf beiden Seiten.
Ich gehe davon aus, dass die Rounds nacheinander abgearbeitet werden, also wenn Round 0 fehlschlägt, wird Round 1 durchfgeführt usw., oder sehe ich das falsch?
Die Gegenseite ist eine Sophos UTM, dessen Internetleitung 1 ist übrigens gerade tot, Bagger an Glasfaser .
Hier ist der Log von der OPNsense:
Code: [Select]
2023-09-14T14:38:34 Informational charon 10[ENC] <2325> generating INFORMATIONAL_V1 request 3229602726 [ HASH N(AUTH_FAILED) ]
2023-09-14T14:38:34 Informational charon 10[IKE] <2325> no peer config found
2023-09-14T14:38:34 Informational charon 10[CFG] <2325> looking for pre-shared key peer configs matching xx.xx.67.42...xx.xx.179.218[xx.xx.179.218]
2023-09-14T14:38:34 Informational charon 10[ENC] <2325> parsed ID_PROT request 0 [ ID HASH ]
2023-09-14T14:38:34 Informational charon 10[NET] <2325> received packet: from xx.xx.179.218[500] to xx.xx.67.42[500] (108 bytes)
2023-09-14T14:38:33 Informational charon 10[NET] <2325> sending packet: from xx.xx.67.42[500] to xx.xx.179.218[500] (460 bytes)