pfSense 2.5 IPsec Problem
-
Soooo, bis auf einen Tunnel laufen die 4 restlichen Fritzbox Tunnel relativ stabil. (Auf die eine FB komme ich selbst nicht drauf)
Ich habe alle auf folgende Werte eingestellt.
P1 MainMode AES-256 SHA512 DH14 LT 3600 Local/Remode ID: IPAddress
P2 AES-256 SHA 512 PFS-Keygroup 14 LT 3600Die ursprüngliche P1 Lifetime von 8h musste zugunsten der DH14 auf 1h reduziert werden. Mehr will die FB nicht.
In der FB CFG wird das P1 Proposal so angegeben "dh14/aes/sha"
Bis auf eine FB habe ich DPD auf 60/5 eingestellt.
Bei der einen musste ich aus unerklärlichen Gründen DPD abschalten, da ich sonst alle 5 Minuten einen reconnect bekommen habe, obwohl DPD auf der FB eingeschaltet sein sollte.Ausserdem liefen die Tunnel keine Stunde durch wenn kein Traffic drüber ging. Eigentlich sollte sowohl die FB (mittels Keepalive IP) und PFsense regelmäßig eine IP auf der Gegenstelle anpingen (Dachte ich zumindest)
Als Workaround lasse ich mit meinem Smart-Home Server Fhem die Tunnelendpunkte alle 60 Sekunden anpingen. Damit bleiben die Tunnel stabil oben.
Mir ist noch aufgefallen, dass das IPsec-Log mit DPD Meldungen zugemüllt wird. Bei der 2.45er Firmware war das nicht so.
Ich hoffe das Hilft dem ein oder anderen.
Gruß
Rubinho -
@jimp said in AWS IPSEC issue in pfsense 2.5:
To ensure you have all of the current known and fixed IPsec issues corrected, You can install the System Patches package and then create entries for the following commit IDs to apply the fixes:
Mit Patch #11442 (Distinguished Name (FQDN) IPsec identifier type not working properly) laufen die Fritten wieder mit fqdn :)
Allerdings bin ich zu bequem, alle Tunnel wieder auf fqdn umzustellen.
Geht ja auch mit einer fiktiven IP.Gruß
Rubinho -
Danke sehr. Habe die Patches eingespielt.
Die Tunnel laufen wieder, leider werden im Dashboard von den 4 nur 2 als aktiv angezeigt, obwohl sie laufen.
Gruß
Thomas -
Leider habe ich auch seit dem Update von 2.4.5 auf 2.5.1 (über 2.5.0) massive VPN Probleme mit IPSec.
Ich kann zwar noch nicht genau sagen wo die genauen Ursachen liegen, aber folgende Ereignisse fanden bei mir statt:
Am 6.4.2021 gab es bei uns am Standort einen geplanten Stromausfall des Energieversorgers.
Alle Systeme wurden vor Stromausfall ordentlich Heruntergefahren.
Die Gelegenheit habe ich genutzt um eine NIC an meiner PC-Sense umzurüsten, da ich noch eine 100mbit Netzwerkkarte drin hatte, welche ein Backup DSL eingebunden hat. Nach erfolgtem wiederanfahren des Netzwerks bemerkte ich weiterhin Leistungsprobleme, welche sich schlussendlich durch Austausch eines vermutlich defekten LAN-Patchkabel beheben ließen. und somit mach meine Sense nun auch schneller ihren Job.
Da ich lange auch keine Updates durchgeführt hatte und ich gern etwas aus dem Paketmanager installieren wollte, machte ich ein Update von der 2.4.5???? auf 2.5.0 und nach dem Neustart (warm) ist alles wieder in Ordnung gewesen.
Am Wochenende (10.4.21) gab es scheinbar einen ungeplanten Stromausfall und nach wiederanfahren bemerkten Kollegen den Ausfall von einem Site to Side VPN welcher über IPsec aufgebaut wurde. Wie die pfSense neugestartet wird sehe ich wie die VPNs Online kommen (gesamt 8 aktive Tunnel) und nach ca. 1 Minute wieder als Down im Dashboard gelistet wurden.
Ich suche per Google nach dem Fehler und finde diesen Beitrag. Bei dem Versuch das System_Patches Package zu installieren meldet mir der Paketmanager -> du verwendest eine Veraltete Version, bitte Updaten. Ich merke nun steht auch die 2.5.1 in der Liste, also installiere ich diese gestern Abend vom Hotelzimmer aus und nach dem Neubooten sehe ich die Situation wie zuvor.
Die Patches werden nach dem Update auf 2.5.1 zwar eingetragen, wenn ich auf Fetch klicke, aber beim Test wird mir gesagt:
Patch can NOT be applied cleanly (detail)
Patch can be reverted cleanly (detail)
(zugegeben genauer habe ich mir die Detail Page noch nicht angesehen)
Ich suche weiter nach dem Thema „pfSense Ipsec und Fritz box“, finde eine Website https://znil.net/index.php?title=FritzBox_-_Site_to_Site_VPN_zu_pfSense_2.5, welche Änderungen der Verschlüsselung in 2.5.x anspricht.
Daher erstelle ich das VPN zu mir nach Hause neu nach dieser Anleitung mit gewissen Änderungen (FQDN anstatt fester IP) und der Aufbau zu mir nach Hause ist erstmal wieder stabil. Ich entschließe mich also am Folgetag (heute) die VPN Konfigurationen neu zu schreiben und dann nach und nach wie sich zugriff per TeamViewer auf einen der Standorte ermöglicht, diese einzuspielen.Jetzt ruft mich heute Früh die Buchhaltung an und sagt „wir haben Probleme mit VPN-XYZ“, (welches über einen eigenständigen LANCom läuft und gar nix damit zu tun hat außer das es die pfSense Durchroutet) auf dem LANCom sehe ich: VPN Aufbau ca seit 1 Minute. Ich prüfe also nebenher das Netz vom Steuerbüro soweit es mir möglich ist und merke ständig VPN auf / Abbau (ob die dort auch eine pfSense haben? - aber unwahrscheinlich, dass dort auch erst die letzten 2 Tage geupdatet wurde).
Bei der weiteren Fehlersuche auf meiner pfSense merke ich, dass wieder ALLE IPsec VPN´s down sind. Auch mein neu erstelltes nach Hause! Das nehme ich zur Kenntnis, kümmere mich aber erstmal um das Buchhaltungs-VPN.
Da ich beim Fremdnetz keine Admin Berechtigungen habe, pinge ich deren Gateway von meinem PC im Büro durch und sehe etwas Eigenartiges, so wie ich Pinge steht die Verbindung stabil!
Machen wir das doch mal mit den eigenen externen Gateways, denk ich mir und: vorrübergehender Erfolg ?!?¿ WTF Seitdem ich alle Gateways Pinge bleiben die Verbindungen online
Setze ich für etwa eine Minute den Ping aus bricht die VPN wieder Weg, starte ich das Anpingen neu, wird innerhalb von weniger als 2 Sekunden die VPN wieder aufgebaut und Nutzbar!Jetzt muss ich sehen wie stabil meine „Notlösung“ ist, damit ich, wenn ich wieder vor Ort bin entscheiden kann wie ich weiter mache.
Derzeit kommen bei mir noch folgende Möglichkeiten in Betracht- Fehlerhafte Internetverbindungen (jedoch Komisch, weil 2 Leitungen mit VPN gleichen Typs mit IPSec an pfSense wie LANCom nicht gehen) und jedoch eine dritte Leitung mit L2TP/IPSec Stabil Funktioniert
Schäden im DSLAM würden ja auch Probleme mit zwei weiteren Gateways mitbringen - Weitere noch nicht gefundene Routing/IPSec/Verbindungshalte Fehler im 2.5.1er Release.
pfSense Quad Core AMD / 8GB / DDR3 / 512GB SSD / 4x NIC 1Gbit WAN 1x NIC 1Gbit LAN
Active Features VPN, Load Balancing, DynDNS, ACME Zertifikat, WOL - Fehlerhafte Internetverbindungen (jedoch Komisch, weil 2 Leitungen mit VPN gleichen Typs mit IPSec an pfSense wie LANCom nicht gehen) und jedoch eine dritte Leitung mit L2TP/IPSec Stabil Funktioniert
-
Aktueller Stand:
Fehler besteht weiterhin.
Sobald ich von einem Client PC Ping an alle IPSec Gatways sende bleiben die Verbindungen geöffnet. Setze ich das Anpingen aus, geht nach etwa 60 Sekunden die Verbindung im Dashboard Offline.
Pinge ich nun von Extern an die pfSense, dauert es 10-15Sekunden bis sich die VPN wieder öffnet
Die Fritzbox definiert die VPN weiterhin als Status Verbunden
Hat jemand ne Idee ?
-
Nach Update auf 2.5.1 (vorher 2.4.x) habe ich ebenso 2 instabile Boxen mit ipsec.
Bei beiden steht eine Fritzbox als Router vor der pf, und eine FritzBox die jeweils die Gegenseite bildet.
Nach genau 120 Sekunden stirbt der Tunnel ab und baut relativ lange neu auf (über 30 Sekunden und mehr). Ein Ping hilft hier nicht, der bricht ebenso ab.
Falls es was zur Sache tut -> in beiden Fällen sehe ich aktuell, dass die pf der Initiator war. In einem Fall, bei dem alles läuft, ist sie beispielsweise der Responder und arbeitet.
Nachtrag -> Als Responder geht die Verbindung schon mal mehr als 120 Sekunden! Aktuell mehrere Minuten bei einem ehem. Störfall. Also in die Phase 1 gehen und "Nur Responder" aktivieren, wen es treffen sollte
-
@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.
-
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 :)
-
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?
-
@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. :)
-
@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 -
@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.
-
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. -
@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.
-
@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.
-
@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
