pfSense 2.5 IPsec Problem
-
Ja das Problem kenne ich, den Tunnel SG-3100 zur Fritz habe ich wieder hin bekommen, zwar nicht stabil aber ich konnte auf die Gegenseite Zugreifen.
Das ein IKEv1 mit Agro Mode.
Der IKEv2 Tunnel zwischen meinen beiden habe ich mit neu anlegen stabil aufbauen können, aber es kommen auf der Gegenseite keine Daten an.
IPsec ist nach meiner Erfahrung mit der 2.5 full broken.
Auch Regelwerk auf allen Seite Floating, IPsec mit any hat auf jeder Seite keine Abhilfe geschaffen.
Habe die Hoffnung gehabt, wenn beide Seiten auf der neuen Version laufen, geht es.Aber nein, keine Chance, ich habe das SG-3100 heute runter gestuft und das SG-1100 folgt morgen.
Stick ist schon betankt.Netgate 6100 & Netgate 2100
-
Hi,
das Problem kann ich bestätigen - habe auch schon ein paar der Fixes eingespielt - aber ebenfalls ohne nachhaltigen Erfolg...
Hoffe es kommt bald ein Fix-Release -
@nocling
Full broken naja...
Das Gefühl hat man wohl, weil aktuell niemand weiß was genau das Problem ist. Allerdings läuft bei mir bisher alles wieder stabil, wobei ich aber auch sagen muss, dass ich noch nicht weiß wo genau das Problem liegt und lag.
Von meinen 5 Tunnel war einer überhaupt nicht betroffen, dass ist ein IKEv1 Tunnel zu einer Fortigate.
Tunnel 2 (pfsense to pfsense ikev2) hatte die Probleme, Tunnel 3, 4 und 5 sind Tunnel zu Fritzboxen und diese hatten die meisten Probleme.Was interessant ist, es läuft immer wieder darauf hinaus, dass etwas mit den PeerIDs bzw. LocalIDs nicht stimmt und anschließend mit dem PSK etwas nicht passt.
Tunnel 2 (pfsense to pfsense) habe ich wieder stabil zum Laufen bekommen, nachdem ich die "Distinquished Names" gegen KeyID Tag bzw. PeerIP ausgetauscht habe.
Bei den 3 Fritzbox Tunnels dachte ich erst, durch ein Neuanlegen hatte ich einen Workaround gefunden, da sie für eine Weile wieder liefen. Nach ca. 24h war aber wieder das gleiche Spiel. Kein Connect und im Log gabs Fehlermeldung ala "invalid ID_V1 payload length, decryption failed".
Mein letzter Versuch war, für die PeerID und LocalID "ipaddr" als Attribut zu nehmen (irgendeine willkürliche IP). Damit laufen die Tunnel nun seit über 24h stabil. Hoffe es bleibt so.Es gibt übrigens bereits ein Commit für das ipsec Widget Problem auf dem Dashboard und dem Bug auf der IPSEC Status Seite
https://forum.netgate.com/post/964827 -
Für mich ist die IPsec Implementation so jedenfalls nicht nutzbar.
Mit der 2.4.5p1 hatte ich über Monate nie einen Aussetzer, wenn der ISP die Pakete nicht verschluckt hat.
Habe da verschiedene Fehler gesehen:
"MAC mismatched" war mal dabei, aber meist "N(AUTH_FAILED)"
Statt 3 Tunnel sind dann unter Status 5 oder mehr aufgetaucht.
Mobile Einwahl geht mal, mal nicht, Surfen geht dann wiederum nicht vom Win Client aus, was bisher auch funktionierte.Und nach dem Neuanlegen habe ich Sense to Sense ja stabil zum Laufen bekommen, gingen nur keine Daten durch.
Da ist IPsec für mich ziemlich put.Die Vorversion läuft so gut, da kann ich die erstmal abwarten oder die sogar ganz auslassen. Fahren ja noch genug 2.4.4er da draußen rum.
IPv6 ist mir mit 21.02 auch um die Ohren geflogen, darüber war kein Internetzugriff mehr möglich. Aber es kann auch an der ARM Hardware liegen, mein kleine x86 Test VM lief in der Beta schon gefühlt ohne Macken. (Aber hier muss ich dann dringend IPv6 und IPSec noch einrichten zum Testen).
Beim SG-3100 kommt ein Problem hinzu was in einer Kernel Panic enden kann, wenn gewisse Lastsituationen zusammenkommen.
So was kann man im Lab echt nicht gut testen, da habe ich volles Verständnis für.Da fliegen einem wegen nem Bug auch ganz andere Firewalls um die Ohren, die weit mehr kosten als das teuerste was Netgate anbietet.
Die fixen das, und vermutlich auch schnell da bin ich mir sicher. Aber ich fahre über den Tunnel meine Backups und die Zeiten wo ich dann halt einfach drauf verzichtet habe sind vorbei.
Wireguard habe ich mal eben auf die Schnelle nicht zum Laufen bekommen, das schaue ich mir dann später ggf. noch mal an. Aber nach den Wochen im Job fehlt mir im Moment privat die Motivation.
Schade, fürs SG-1100 hätte ich den Crypto Treiber gerngehabt, dann gibt es ihn halt später.
-
Servus
Ich hab mit meinen 5 IPsec Tunneln zu Fritzboxen natürlich den Hauptgewinn erziehlt.
Kein einziger Tunnel funktioniert nach dem Update auf 2.5 :/
Dazu kommt, dass ich nicht auf jede Fritz von der Ferne draufkomme.Mich wundert, dass das nicht schon vorher aufgefallen ist.
Zurück auf 2.4 will ich allerdings auch nicht. Ich kotze :(
[Pfsense 2.4] Supermicro A1SRI-2558F@Atom C2558 4Gb RAM
[Pfsense 2.4] Jetway NF9D@Atom D2550 + AD3INLAN-G Expansioncard (3x Intel 82541PI Gigabit Controller) -
@rubinho
workaround: kopiere die P1s der tunnel und lege die P2s mit den gleichen einstellungen an. dann solltest du erstmal wieder drauf kommen. anschließend ändere die peer und local IDs von distinguished auf "IP Adresse" (pfsense) und "ipaddr" (Fritzbox).
Nimm dort eine wilkürliche IP wie z.B.: 17.18.19.10. Damit laufen alle Fritzbox Tunnel aktuell reibungslos. -
Mit diesem Patch hat‘s wieder funktioniert ...
https://forum.netgate.com/topic/160817/ipsec-dashboard-widget-not-displaying-proper-status?lang=de
-
@esquire1968-0 said in pfSense 2.5 IPsec Problem:
https://forum.netgate.com/topic/160817/ipsec-dashboard-widget-not-displaying-proper-status?lang=de
ist doch oben schon geschrieben
-
@m0nji
Erstmal danke für den Workaround.Was den Patch angeht, so dient dieser doch nur zur richtigen Anzeige im Dashboard bzw. der IPsec Status Seite.
Wobei der Patch des Widgets bei mir nicht richtig funktionert. Wenn nur ein Tunnel steht, werden wir alle grün/aktiv angezeigt.
Aber das ist ja nicht mein Problem gewesen, bzw. hat mich in erster Linie weniger interessiert, da mir ein funktionierender Tunnel lieber ist, als die Anzeige ;)Das gute daran ist, im Zuge der Tunnelanpassung, habe ich die Proposals auf den aktuellen Stand bringen können, inkl. Main Mode.
-
@m0nji
Sorry! -
ich hab zwei pfSense per ipsec verbunden, auf beiden keine Probleme nach dem jeweiligen update, also der tunnel lief auch nachdem nur eine der Boxen upgegraded war. An der ersten sind zwei weitere Ipsec angebundenm einer mit cisco und eine fritzbox. Die fb mag gar nicht, egal was ich mache ob ich den tunnel neu anlege oder keyid nutze... egal was, ich bekomme einen hash fehlerhaft auf der box mit code 0x2020, auch wenn die pfSense die Rückmeldung bekommt steht ein hashfehler im log. Downgrade auf 2.4.5 und das ganze lief sofort wieder mit den selben Settings.
Das lustige ist ich hab dann aus Spaß die zweite pfSense an die FB angebunden und der tunnel lief lustiger weise sofort aber auch nicht stabil da er relativ zeitnah abbricht und der Aufbau immer länger dauert. Die freeswan version unter 2.4.5 läuft dagegen rock solid als ikev1 aggressive. Es gibt ja schon einige patches die auch configfehler beheben, das dürfte aber den hashfehler von mir auf der ersten pfSense nicht beeinflussen.
Ich warte jetzt erst mal die 2.5.0 p1 version ab, die wurde schon angelegt im repository und die gröbsten Schnitzer wurden schon eingetragen.
-
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?
