Falsche ID in Phase 1 bei redundanten IPSec-Verbindungen

[vpx]

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 ;D.

Hier ist der Log von der OPNsense:

Code Select Expand

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)

[vpx]

Nachdem die erste Leitung der Gegenseite weder online war und ich alle Rounds wieder aktiviert hatte, steht die Verbindung wieder.

Bevor ich die Rounds aktiviert hatte kam folgender Fehler:

Code Select Expand

2023-09-14T15:32:56 Informational charon 06[ENC] <2374> generating INFORMATIONAL_V1 request 3755966613 [ HASH N(AUTH_FAILED) ]
2023-09-14T15:32:56 Informational charon 06[IKE] <2374> found 1 matching config, but none allows pre-shared key authentication using Main Mode
2023-09-14T15:32:56 Informational charon 06[CFG] <2374> looking for pre-shared key peer configs matching xx.xx.67.42...xx.xx.30.162[xx.xx.30.162]

Wieso schlägt die Verbindung in allen anderen Rounds außer 0 fehl auch wenn die IDs und IPs zusammen passen?

Unter "VPN: IPsec: Pre-Shared Keys" habe ich alle 4 möglichen Kombinationen zwischen "Local Identifier" und "Remote Identifier" eingetragen. Der PSK ist bei allen 4 der gleiche.

[vpx23]

Nach etwas Recherche in der strongSwan Dokumentation bin ich auf MOBIKE gestoßen.

https://docs.strongswan.org/docs/5.9/features/mobike.html

Ein Protokoll, welches eine nahtlose Veränderung der öffentlichen IPs erlaubt, also genau das was ich benötige für die Redundanz.

Leider wird das erst ab IKEv2 unterstützt und die Sophos UTM wurde leider nicht mehr auf IKEv2 aktualisiert, damit sie kein Konkurrent für die neue SFOS Firewall ist. Wäre auch sinnvoll die MOBIKE Kontrollbox auszublenden wenn in der Dropdown-Liste IKEv1 ausgewählt wird.

Von UTM zu UTM scheint das auch mit IKEv1 zu funktionieren, da die UTM das wohl außerhalb von strongSwan über 2 Tunnel mit "Uplink Balancing" löst.

https://community.sophos.com/utm-firewall/f/german-forum/115525/sophos-utm-multiple-s2s-ipsec-vpn-mit-failover-tutorial-de

Die Lösung funktioniert aber nicht über Kreuz, sondern jeweils mit 2 feste Paaren.