Störung IPSec Aufbau nach Interntdowntime
-
Hallo in die Runde,
dies ist mein erster Post, da ich auch etwas mit meinem Latein am Ende bin und meine Recherche bisher nicht von Erfolg gekrönt.
Folgender Umstand bereitet mit Kopfzerbrechen:
Wir haben eine zwei Standorte mittels IPSec Site-2-Site verbunden. Auf beiden Seiten steht jeweils eine pfSense in Version 2.6.0 und die Verbindung wird mit IKEv2 aufgebaut.
Die Konfiguration hat auch bisher tadellos funktioniert. Jetzt gab es am zweiten Standort einen kurzen Internetausfall, jedoch konnte die IPSec Verbindung nach Wiederherstellung der Internetverbindung nicht mehr automatisch aufgebaut werden. Erst nachdem ich den IPSec Dienst am zweiten Standort manuell neu gestartet habe, wurde die Verbindung wieder hergestellt.
Aus dem IPSec Log habe ich dazu folgenendes heraus gelesen:initiating IKE_SA con167[1045073] to "WAN-IP Standort 2"
IKE_SA con167[1045073] state change: CREATED => CONNECTING
configured proposals: IKE:AES_CBC_256/AES_XCBC_96/PRF_AES128_XCBC/ECP_512_BP
sending supported signature hash algorithms: sha256 sha384 sha512 identity
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from "WAN-IP Standort 1"[500] to "WAN-IP Standort 2"[500] (336 bytes)
received packet: from "WAN-IP Standort 2"[500] to "WAN-IP Standort 1"[500] (36 bytes)
parsed IKE_SA_INIT response 0 [ N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN notify error
configured proposals: IKE:AES_CBC_256/AES_XCBC_96/PRF_AES128_XCBC/ECP_512_BP
IKE_SA con167[1045073] state change: CONNECTING => DESTROYINGSo wie es aussieht wird der "IKE_SA_INIT request" nicht ordnungsgemäß beantwortet und dadurch kommt es zur Meldung "received NO_PROPOSAL_CHOSEN notify error".
Gibt es eine Möglichkeit den Fehler zu beheben, ist es womöglich ein Softwarefehler?Vielen Dank für die Unterstützung! :)
Beste Grüße,
Henry -
@hnoack85
Hallo,was loggt Standort2?
Ich hätte den Verdacht, dass die 2. Seite keinen passenden Peer Identifier sieht. Was ist dort eingetragen und was kommt tatsächlich an?
Eventuell wurde Standort1 im Zuge des "Internetausfalls" auf CG-NAT umgestellt?BTW:
Auf beiden Seiten steht jeweils eine pfSense in Version 2.6.0
Eine Erklärung für das Nicht-Upgraden ist hier praktisch obligatorisch. Anderenfalls drohen schlaue Weisungen oder gar ein regelrechter Shit-Storm.
-
vielen Dank für deine Antwort. :)
Ich habe den Auslöser für das Fehlverhalten gefunden. Leider wurde an Standort 2 mit einem doppelten NAT bei der WAN Verbindung gearbeitet. Dadurch kommt es zu einer falsch übergebenen IP, die dann natürlich nicht in der IKEv2 Config steht.
Das Update weg von Version 2.6.0 steht schon auf meinem Zettel. :)
-
@viragomann said in Störung IPSec Aufbau nach Interntdowntime:
Eine Erklärung für das Nicht-Upgraden ist hier praktisch obligatorisch. Anderenfalls drohen schlaue Weisungen oder gar ein regelrechter Shit-Storm.
Antworten
naja der Sturm nicht ;) aber da 2.7 und 2.7.2 schon etliche Updates gerade bei IPsec gemacht haben, würde es sich natürlich SEHR anbieten, erstmal auf den aktuellen Stand zu kommen.
@hnoack85 said in Störung IPSec Aufbau nach Interntdowntime:
etzt gab es am zweiten Standort einen kurzen Internetausfall, jedoch konnte die IPSec Verbindung nach Wiederherstellung der Internetverbindung nicht mehr automatisch aufgebaut werden. Erst nachdem ich den IPSec Dienst am zweiten Standort manuell neu gestartet habe, wurde die Verbindung wieder hergestellt.
Aus dem IPSec Log habe ich dazu folgenendes heraus gelesen:Das hört sich sehr danach an, als könnte zwar Seite A mit B aber B nicht mit A die Verbindung aufbauen, was u.a. an NAT wie @viragomann geschrieben hat liegen kann. Ich würde da empfehlen auf beiden Seiten mal in der P1 den Verbindungsaufbau zu disablen (reply only) damit keine der beiden Seiten die Verbindung aufbaut. Dann manuell disconnecten. Dann auf Seite A versuchen aufzubauen und das ganze Spiel nach nochmals mit Seite B. Dann bekommt man schnell raus, ob es in beide Richtungen sauber läuft oder nicht, was ich hier denke nicht der Fall ist.
Ansonsten ist der NO_PROP Error vielfältig, das liest sich im ersten Moment dann wie ein P1 oder P2 Encyption Fehler - also nicht exakt gleich eingestellte Phasen. Zusätzlich: wenn beide Seiten Sensen sind, dann nutzt da bitte auch AES-GCM-256 und nicht CBC wie es im proposal steht. Ich würde da beide Seiten fix auf AES-256-GCM, AES-XCBC (oder SHA-256) und DH20 stellen (ecp256 oder ecp384). Alles andere ist eigentlich unnötig überzogen. Ich weiß nie warum irgendwelche Hersteller da statt GCM sauber zu unterstützten immer noch mit "ja aber wir machen SHA512 und DH 21 mit ECP521!" - ja toll, aber das wichtige wäre GCM weils die CPU/Crypto entlastet und schneller ist und nicht irgendwelche Hashes oder Secrets die dann ultra doll verschlüsselt sind
Cheers
\jens
