pfSense 2.5 IPsec Problem
-
@jegr ja hab ich auch schon probiert aber dann baut er glaub sobald p1 abgelaufen ist gar nicht mehr auf, ich stell noch mal auf 28800
im debug steht jetzt nur noch als ergänzung folgendes
Jul 4 00:34:15 charon 86458 07[IKE] <con200000|56> received INVALID_ID_INFORMATION error notify
Jul 4 00:34:15 charon 86458 07[IKE] <con200000|56> 48: C8 72 A1 0F 42 86 5C 63 FA 5C 10 6A 3E 36 E3 32 .r..B.\c..j>6.2
Jul 4 00:34:15 charon 86458 07[IKE] <con200000|56> 32: CD 11 43 CF 36 36 5E 3A C2 90 D9 22 2E 1D 62 C6 ..C.66^:..."..b.
Jul 4 00:34:15 charon 86458 07[IKE] <con200000|56> 16: 68 60 75 3B 41 D7 28 35 91 9F 3F D7 55 C2 3D 9C h`u;A.(5..?.U.=.
Jul 4 00:34:15 charon 86458 07[IKE] <con200000|56> 0: C7 21 EF 19 96 B9 E6 FA 4A 50 AD 84 0A CB 9C 09 .!......JP......
Jul 4 00:34:15 charon 86458 07[IKE] <con200000|56> Hash => 64 bytes @ 0x804986000
Jul 4 00:34:15 charon 86458 07[ENC] <con200000|56> parsed INFORMATIONAL_V1 request 2635989907 [ HASH N(INVAL_ID) ] -
@t-np Nochmal zum validieren: du bist aktuell wieder auf 2.5.1? Hast du mal testweise auf 2.5.2RC aktualisiert?
-
@jegr said in pfSense 2.5 IPsec Problem:
testweise auf 2.5.2RC
ich hab zwei gegenstellen eine ist auf 2.6, die andere auf 2.5.1-RELEASE, beide mit identischem verhalten jede stunde trennung. egal ob in p1 reauth an oder aus und egal ob mit wizard auf frittenseite erstellt oder mit config file. ich kanns zum Spaß auch mit der 2.5.2 probieren.
ich hab die p1 lifetime jetzt wie von dir vorgeschlagen auf 28800 gestellt im log taucht nach einer stunde anstatt dem hash fehler folgendes auf
Jul 4 21:15:07 charon 86458 15[IKE] <con200000|87> schedule delete of duplicate IKE_SA for peer 'xxxx.myfritz.net' due to uniqueness policy and suspected reauthentication
Jul 4 21:15:07 charon 86458 15[IKE] <con200000|87> detected reauth of existing IKE_SA, adopting 1 children and 0 virtual IPs
immer exact alle 3240 Sekunden = rekeyzeit des p2 zu den zeiten wird dann offensichtlich auch der tunnel getrennt und danach wieder neu aufgebautder p2 rekey scheint dafür vorher sauber durchgeführt worden zu sein
Jul 4 20:56:01 charon 86458 07[CHD] <con200000|87> CHILD_SA con200000{161} state change: REKEYING => REKEYED
Jul 4 20:56:01 charon 86458 07[CHD] <con200000|87> CHILD_SA con200000{164} state change: INSTALLING => INSTALLED
Jul 4 20:56:01 charon 86458 07[IKE] <con200000|87> CHILD_SA con200000{164} established with SPIs cd51a8b5_i 3caf657a_o and TS 192.168.0.0/17|/0 === 192.168.178.0/24|/0Jul 4 21:02:32 charon 86458 08[CHD] <con200000|87> CHILD_SA con200000{161} state change: DELETED => DESTROYING
Jul 4 21:02:32 charon 86458 08[CHD] <con200000|87> CHILD_SA con200000{161} state change: DELETING => DELETED
Jul 4 21:02:32 charon 86458 08[IKE] <con200000|87> closing expired CHILD_SA con200000{161} with SPIs cf49e8f2_i 228c529b_o and TS 192.168.0.0/17|/0 === 192.168.178.0/24|/0
Jul 4 21:02:32 charon 86458 08[CHD] <con200000|87> CHILD_SA con200000{161} state change: REKEYED => DELETING -
@t-np Wenn es alle 3240s ist, dann hat es mit P2 Handling zu tun. Dann wird die Fritte (mal wieder) irgendein Handling nicht mitmachen, dass übermittelt wird. Du kannst ab den neueren Varianten 2.5+ in P1 einstellen, was er bei einem SA Close Event machen soll. Die 3240 sind ja die Rollover Time, bei der beide Seiten eigentlich eine neue Child SA etablieren (mit neuen Keys). Dann laufen Übertragungen über diese SA während die alten Verbindungen oder irgendwelche Hänger noch auf der alten SA dann noch ein paar Restsekunden (360) Zeit haben. Da die Fritte ggf. mit mehreren Tunneln gleichzeitig (mal wieder) ein Problem hat (gab schonmal ein FW Update was IPsec Probleme gefixt hat), wird vllt statt parallel die Phasen zu halten, die alte abrupt beendet und die neue hochgezogen. Was halt komplett am Sinn des Ganzen vorbei geht.
Möglichkeiten noch zu testen wären da:
-
In der P2 der Sense die LifeTime und Rekey Time sowie Rand Time löschen. (Werte rausnehmen). Das sollte dazu führen, dass Lifetime nicht mehr 3600 sondern 3960 wird und die Rekey Time 3600. Eventuell kommt die Fritte damit besser klar wenn erst wirklich nach 1h das Rekeying kommt und nicht vorher.
-
Dead Peer Detenction rausnehmen. Fritzen haben damit in den neueren Versionen böse Probleme gehabt/gemacht, mussten wir zumindest bei einigen Kunden rausnehmen.
-
Child SA Close Action: wenn die beiden vorherigen nichts bringen, hier ggf. statt default mal auf restart/reconnect gehen.
Eventuell hilft es auch, die pfSense auf Responder-only zu schalten (Start Action), damit die Fritzbox immer der Initiator ist und quasi "den Ton angeben" kann.
Muss ich mal in die Testbox werfen.
-
-
@jegr said in pfSense 2.5 IPsec Problem:
Möglichkeiten noch zu testen wären da:
In der P2 der Sense die LifeTime und Rekey Time sowie Rand Time löschen. (Werte rausnehmen). Das sollte dazu führen, dass Lifetime nicht mehr 3600 sondern 3960 wird und die Rekey Time 3600. Eventuell kommt die Fritte damit besser klar wenn erst wirklich nach 1h das Rekeying kommt und nicht vorher.
Dead Peer Detenction rausnehmen. Fritzen haben damit in den neueren Versionen böse Probleme gehabt/gemacht, mussten wir zumindest bei einigen Kunden rausnehmen.
Child SA Close Action: wenn die beiden vorherigen nichts bringen, hier ggf. statt default mal auf restart/reconnect gehen.
hab die default werte jetzt mal im p2 gesetzt.
probiere dann auch noch dpd auszuschalten,
die child action hatte ich auch schon mal gesetzt, ich probiers jetzt aber mal etwas strategischer und mache eins nach dem anderen und evtl. auch mal in Kombination.ich hab bisher die pfsense eh immer nur als responder gesehen ich befürchte die fritte wird gar nicht als responder laufen auch wenn man wollte... kann ich aber auch mal probieren
-
@jegr said in pfSense 2.5 IPsec Problem:
Eventuell hilft es auch, die pfSense auf Responder-only zu schalten (Start Action), damit die Fritzbox immer der Initiator ist und quasi "den Ton angeben" kann.
Muss ich mal in die Testbox werfen.
Das hat zumindest bei mir in zwei akuten Fällen wie o.g. schon geholfen. Die Timings stehen auf Standard. Bei zwei weiteren war es scheinbar zufällig, aber hier ist ebenso die pf Responder.
-
@jegr vorhin kam nen update für meine fotzbox... v7.26. tunnel läuft seitdem, ich hab aber zusätzlich auch die drei maßnahmen von dir quasi kurz vorher aktiviert. P1 startet zwar immer noch jede stunde vom timer neu aber es scheint dass die states nicht zurückgesetzt werden, ich hab zumindest noch keine rdp trennung mitbekommen über den tunnel.
-
Gibt es schon was Neues hierzu? Wurde seitens AVM oder pf/strongswan was unternommen, oder bleibt es bei unseren "Fixes"?
Eine Zusammenfassung wäre dann nochmal super. Ich habe aktuell noch lediglich die "Responder" Geschichte aktiv, das genügt einigermaßen. Gefühlt alle paar Wochen hängt es dann aber doch mal richtig.
-
Bei mir läuft es mit DH2 in P1 und P2 wieder stabil.
Alles andere ist mit der Fritz als Gegenstellt gebastel und nicht stabil betreibbar.
Ist leider ein Albtraum als Gegenstelle. -
Leider nur mit (überholtem) Aggressive Mode (), SHA-512 und DH2 (völlig wilde Zusammenmischung als hätte jemand gewürfelt) sinnvoll nutzbar.
- IKE v1
- Aggressive Mode
- AES-256 (CBC)
- SHA-512
- DH Group 2
Zusätzlich sinnvoll:
- pfSense als: "Responder only" - FB Verbindung aufbauen lassen
- Wenn es Probleme gibt, dass alle Stunde die Verbindungen abreißen: DPD ausmachen, dead peer detection ist wohl ziemlich guffelig auf der Fritte.
Mit Responder und ohne DPD liefen die eigentlich halbwegs gerade, alles andere liegt eher an der Rumpelkammer von AVM.