pfSense 2.5 IPsec Problem

[s.pfueller]

@sebden Meine derzeitige finale Lösung war auf eine zweite SSD pfSense 2.4.4 neu zu installieren, die Config zu importieren.
Sofort lief alles wieder vollständig Fehlerfrei, er hat zwar gemeckert "die Konfigurationsdatei stammt von einer neueren Version" hat aber keine Probleme gemacht.

Leider muss ich sagen für mich war dieses Update auf 2.5.x eine einzige Katastrophe und ich bin echt am nachdenken mir opnSense anzusehen.

[JeGr]

Ja das Rekease war sicher mehr als suboptimal. Trotz dessen:

@s-pfueller Dann viel Spaß beim nächsten OPN Release, die Jungs müssen auch endlich mal auf FreeBSD 12 und die ganzen neuen toolchains updaten. Hier wurde viel pfsense zugeschrieben was an Upstream Projekten lag. Sei es openvpn oder strongswan oder FreeBSD selbst. Und so oft wie ich IPsec Probleme dort im Forum bekomme ist beim Nachbarn der Rasen auch nicht grüner ;)

Zudem hatte es sicher auch einen Grund, dass AVM die letzten 3 FWs immer wieder "Verbesserung von IPsec" in den Patchnotes hatte. Komisch, dass es egal bei welcher *sense vor allem gerne Probleme mit den Fritzboxen sind.

Davon abgesehen: ich würde wenn möglich eher mal auf einer Testbox 2.5.2 testen was da los ist. Oder auch mal 2.6. Bei IPsec ist zudem jetzt selektierbar was beim Abbau der P2 passieren kann. Damit kann man auch experimentieren. Aber wenn sich AVM Leute schon für den Zustand von VPN in der Box entschuldigen... nunja. ;)

Cheers :)

[t-np]

ich bin jetzt mittlerweile auf einem 2.6 beta release gelandet wegen dem routing bug bei portfreigaben mit multiplen gateways. Grundsätzlich läuft mein tunnel mit der fritzbox seit der 2.5 immer noch eher semi.

Ich habe es nicht hinbekommen das der rekey sauber läuft. Zum einen muss ich in Phase 1 den rekey ausstellen da der sonst dazu führt das der tunnel irgendwann gar nicht mehr aufgebaut wird. und zum anderen wird der rekey in P2 zwar gestartet, führt aber dazu dass dann zwei tunnel gleichzeitig offen sind und beide nach knapp einer stunde wie in den settings angegeben ist wieder verworfen werden und die Verbindung dann aber zuverlässig wieder aufgebaut wird.

Ich habe auch keinen unterschied zwischen einer custom config mit aggressive oder main mode und einem tunnel, den ich einfach über die fritzoberfläche angelegt habe festgestellt. Außer dass der fritz wizard nur mit DH2 statt DH14 funktioniert.

Ich weiß ja nicht wie eure tunnel rekeyen oder ob ihr das überhaupt mitbekommt, aber ich nutze auch voip über die leitung und mir gehen die unterbrochenen gespräche auf die nerven...

Hat irgendjemand wirklich einen sauber funktionierenden Tunnel wo der rekey funktioniert bei einer pfsense > 2.5 oder trennt bei euch der Tunnel genauso wie bei mir nach ner stunde und verbindet dann einfach neu ohne großartige downtime und es stört euch einfach nicht?

[JeGr]

@t-np said in pfSense 2.5 IPsec Problem:

ich bin jetzt mittlerweile auf einem 2.6 beta release gelandet wegen dem routing bug bei portfreigaben mit multiplen gateways. Grundsätzlich läuft mein tunnel mit der fritzbox seit der 2.5 immer noch eher semi.

Routing Bug ist schon mit 2.5.2 (-RC) raus.

Hat irgendjemand wirklich einen sauber funktionierenden Tunnel wo der rekey funktioniert bei einer pfsense > 2.5 oder trennt bei euch der Tunnel genauso wie bei mir nach ner stunde und verbindet dann einfach neu ohne großartige downtime und es stört euch einfach nicht?

Wir haben locker 2 Dutzend Tunnel. Wir haben dutzende Kunden mit Tunneln. Wir haben auch Dutzende pfSense Kunden von denen einige schon 2.5 problemlos nutzen mit Tunneln. Überall läuft IPsec wie IPsec laufen soll. Wenn es irgendwo Murks gab/gibt, dann zu >90% weil es gammlige Fritzboxen am anderen Ende waren. Sorry dass ich das so schreibe, ich hab keine Probleme was AVM und die Boxen angeht wenn es um ihren Hauptzweck geht. Aber VPN können die Dinger einfach nicht vernünftig. Und wenn ich dann nen Ticket dazu bei AVM aufmache und da kommt nach einigem Geschwurbel dazu, dass das halt alles alt und suboptimal läuft... was soll ich dann sagen/machen? Ich hab hier die vielfältigsten Gegenstellen. Sophos, Checkpoint, Cisco. Fortigate, Bintec, DD-WRTs... Selbst Azure selbst oder AzureVMs. Das tut.

Aber ich hab hier ne Box rumschimmeln und ne 2.6dev Gegenstelle. Nächste Woche kann ichs gern explizit in der Konstellation testen. Wenn ichs bis Mittwoch nicht hinbekomme, gern nochmal erinnern, dann mach ichs spätestens Freitag im Stream beim Usergroup Meetup. :)

[t-np]

@jegr said in pfSense 2.5 IPsec Problem:

Wir haben locker 2 Dutzend Tunnel. Wir haben dutzende Kunden mit Tunneln. Wir haben auch Dutzende pfSense Kunden von denen einige schon 2.5 problemlos nutzen mit Tunneln.

ich hab auch zwei weitere Tunnel die auch mit dem ersten 2.5er release mit den ganzen bugs sauber liefen, nur die fritzbox machte seit der 2.5 Probleme. Mit der 2.4 lief das zuvor ein jahr lang auch absolut problemlos. Ich bin auch voll bei dir das die FB implementierung das kernproblem ist. Nur wie du schon sagst, bis die sich bewegen sind wir auf 3.0...

Ist die Frage ob man den Tunnel mit der aktuellen Implementierung nur mit passenden Settings überhaupt zuverlässig für eine Zeitspanne länger als eine Stunde am stück ohne Reconnect betrieben bekommt, ich hab's bis jetzt nicht hinbekommen.

das ich jetzt auf der 2.6 dev hängengeblieben bin, liegt nur daran das ich einen downgrade vermeiden wollte und auch nicht den snapshot zurückspielen wollte. Da es mit dem dev sofort lief und auch sonst seit Wochen keine Probleme bestanden, bin ich drauf geblieben und warte jetzt den release ab.

Wenn ich vielleicht irgendwann mal zeit bekomme und meinen proxmox host daheim hochfahre, würde ich die fbox degradieren und eine virtuelle pfsense nutzen, es war mit der fbox eigentlich ok das letzte jahr, nur aktuell nicht produktiv nutzbar.

danke dass du es auch mal probieren möchtest, wichtig wäre dass der rekey nach der knappen stunde funktioniert da die fbox offensichtlich nicht länger wie LT3600 mit der PFSense >2.5 verbinden will, ich hab hier ne FRITZ!Box 7580 FRITZ!OS: 07.25 - Version aktuell, wie gesagt der Aufbau funktioniert bei mir auch mit dem fbox wizard lan2lan mit
P1 AES 256 SHA512 DH2 und reauth 0
P2 AES 256 SHA512 DH2 LT3600

[JeGr]

@t-np said in pfSense 2.5 IPsec Problem:

das ich jetzt auf der 2.6 dev hängengeblieben bin, liegt nur daran das ich einen downgrade vermeiden wollte und auch nicht den snapshot zurückspielen wollte. Da es mit dem dev sofort lief und auch sonst seit Wochen keine Probleme bestanden, bin ich drauf geblieben und warte jetzt den release ab.

2.6 wird aber ein ganzes Weilchen dauern. Deshalb die Info, dass es auch in 2.5.2 gehen sollte, denn der Release ist "nah" :)

danke dass du es auch mal probieren möchtest, wichtig wäre dass der rekey nach der knappen stunde funktioniert da die fbox offensichtlich nicht länger wie LT3600 mit der PFSense >2.5 verbinden will, ich hab hier ne FRITZ!Box 7580 FRITZ!OS: 07.25 - Version aktuell, wie gesagt der Aufbau funktioniert bei mir auch mit dem fbox wizard lan2lan mit

Ich würde das direkt mal für Freitag und die Usergroup mitnehmen und dort mal durchspielen. Da bekommen wir dann sicher ne Stunde rum um zu sehen ob er immer noch läuft.

Baut sich der Tunnel ab oder ständig neu auf?

Ansonsten bau ich das einfach mit entweder der Kabelfritte oder der DSLfritte auf mein Labtarget draußen. Wenn du Zeit hast, kannst du ja am Freitag dazu stoßen.

[NOCling]

Gerade noch mal geschaut, 21.05 - 7590 mit 7.27, Tunnel fliegt immer wieder weg.

Lasse jetzt mal nen Ping laufen und schaue ob die Fritz den dann halten kann, denn gesetzt ist die Checkbox in der Fritz Tunnel dauerhaft halten.
Scheinbar macht die das aber trotzdem nicht mehr, das doch einfach nur nen Kackbox.

[t-np]

@jegr sorry, hab's gestern leider nicht gepackt, musste ne Nachtschicht einlegen und hab zu dem Zeitpunkt gepennt...
zu deinen Fragen, der tunnel wird regelmäßig nach ca. 1h P1 laufzweit getrennt und dann aber zuverlässig mit der nächsten initierung von der frittenseite aus wieder aufgebaut. Was ich gesehen habe ist das der rekey vorgang in der p2 gestartet wird und dann zwei p2 tunnel offen sind und der rekey hier offensichtlich sauber funktioniert. Bei abgeschaltetem Rekey auf p1 bricht tunnel nach max einer stunde ab, hab dazu jetzt kein logeintrag.

Wenn ich p1 rekey aktiviere mit lt3600 wird der rekey versucht, bricht aber wegen folgendem ab
Jul 3 07:07:06 charon 17338 14[IKE] <con200000|1730> received INVALID_ID_INFORMATION error notify
Jul 3 07:07:06 charon 17338 14[ENC] <con200000|1730> parsed INFORMATIONAL_V1 request 1231850516 [ HASH N(INVAL_ID) ]

ich hab jetzt mal ike debug erhöht und warte jetzt mal ab was da raus kommt.

[JeGr]

@t-np Also Phase 1 sollte so ~28800 haben als Zeit, P2 sollte bei ner Stunde liegen. Bin leider noch nicht zum Test gekommen, werde aber das nächste Woche beim Test mal einplanen.

[t-np]

@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) ]

[JeGr]

@t-np Nochmal zum validieren: du bist aktuell wieder auf 2.5.1? Hast du mal testweise auf 2.5.2RC aktualisiert?

[t-np]

@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 aufgebaut

der 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|/0

Jul 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

[JeGr]

@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.

[t-np]

@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

[sebden]

@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.

[t-np]

@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.

[sebden]

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.

[NOCling]

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.

[JeGr]

@sebden Was @NOCling sagt.

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.