[Sammelthread] pfSense & OPNsense (Firewall- und Routing-Appliance)

  • Ersteller Gelöschtes Mitglied 63700
  • Erstellt am
@fard dwalling
Die ganzen AltenKnacker ;) die ihre Wege gegangen sind und dan an pfSense hängen blieben, erzählten mir eigentlich nie so wirklich von irgendwelchen speziellen Vorzügen (sowas wie man bei OPNsense z.B. mit dem Menü immer macht...). Das beschränkte sich primär irgendwie immer auf mehr oder weniger, "es läuft".

Dachte erstmal die halten sich für elitär und haben keine Lust da groß was zu erzählen, aber so mit der Zeit wir diese Aussage immer ergiebiger...
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Dir ist schon klar, daß 2.5 ein dicker Major ist? Oder was meinst du?
Die Empfehlung, stressfrei laufende Systeme nicht sinnlos zu updaten, ist glaub ich so alt wie PDP-7... Mir fällt erstmal nichts ein warum das für pfSense nicht gelten sollte.

Jedenfalls war mit 2.4.5p1 erstmal ziemlich lange Ruhe.
 
Ziemlich lang Ruhe finde ich jetzt bei einem heiklen System wie Firewall aber nicht unbedingt von Vorteil.
Schon gar nicht, wenn ein FreeBSD als Unterbau dient, welches schon längere Zeit nicht mehr supported wird...
 
Welche security holes aus der 11.xx von 2.4.5p1, die dann natürlich pfSense auch betreffen, wurden mit 12 denn behoben? Das muss ich natürlich schon wissen, wenn ich soetwas bemängeln möchte.
 
Es hinterlässt bei mir einfach ein kleines Bauchgrummeln.
Genauso wenn jemand sagt, er setzt eine Linux VM einmal auf und installiert nie Updates. Never Touch und so.
Gleiches hab ich auch schon zu einem Exchange gehört. Und wenn du dann siehst, das auf dem wirklich über 2 Jahre keine CU Updates installiert wurden... Brrr..
 
Du hast das glaub ich aus versehen bisschen verschwurbelt jetzt...
Es hat hier ja niemand behauptet, daß wenns denn läuft, man nie updaten sollte. Wenn es Sicherheitsprobleme gibt, dann ist das meist kein Spaß.

Von der Versionsgeilitis selbst, wurde jedenfalls schon vor zig Jahren geheilt. Neues, hat immer wieder seine eigenen Probleme. So wie das ältere, bis es in seiner bsiherigen Form genug Zeit hatte zu reifen.
Veränderungen, sind nicht zwangsläufig Verbesserungen. Neuartig wie Modern, sind keine Synonme für Besser oder Einfacher. usw.

Gereifte Programme kannst du heute an einer Hand abzählen. Mit einer Firewall die auf dem development branch r357046 läuft, der ein ganzes Stückchen nach 11.3 rauskam, habe ich überhaupt keine Probleme, solange diesen Branch nicht irgendwelche Probleme bezüglich der Funktionsweise von pfSense betreffen. Oder solange etwas was ich an pfSense nutze/nutzen möchte, nicht betroffen ist.

Ich wüsste nicht wovon ich da Bauchgrummel bekommen sollte, wenn ich ausgereifte Software nutze. Und 2.4.5-p1 ist ordentlich gereift bis es endlich so heißen dürfte. Die release notes zeigen das eindeutig ;)
 
Auch schön ich bin pünktlich zum release von 2.5 auf Opnsense gewechselt weil mich das UI von PF nur noch genervt hat :rolleyes2:
 
Dir ist schon klar, daß 2.5 ein dicker Major ist? Oder was meinst du?
Die Empfehlung, stressfrei laufende Systeme nicht sinnlos zu updaten, ist glaub ich so alt wie PDP-7... Mir fällt erstmal nichts ein warum das für pfSense nicht gelten sollte.

Jedenfalls war mit 2.4.5p1 erstmal ziemlich lange Ruhe.
Die relative Ruhe ist nicht auf Stabilität zurück zu führen, sondern darauf, dass Updates zuletzt nur selten kamen. Wie Du richtig sagst, wenn Software läuft und kein Update gemacht wird, dann läuft es halt. So ist das bei jedem Stück Software. Ich kann ein laufendes OPNsense auch 6 Monate lang nicht updaten und dann ein Major Update machen. Dann läufts auch stabil. Ist in beiden Fällen dasselbe und kein Kriterium für oder wider.

Ich bin ursprünglich von OPNsense auf pfsense gegangen und habe die Ruhe genossen. Wenn ich ein zweiwöchiges OPNSense-Update gesehen habe, dann zuckte mein Zeigefinger, wider jede Vernunft 8-). Und das macht halt ab und an Ärger. Seit der de facto Abkündigung von Open Source durch pfsense bin ich jetzt wieder zurück auf OPNsense. Und mache nur noch jedes vierte oder fünfte Update mit ... (glaube ich ... nein, will ich ... oder besser: Werde ich !!!) ... wer's glaubt :d

My2Cents: Sind beides gute Firewalls, man kann fast alles damit machen, viel lernen, die Familie stressen, etc. Münze werfen und auswählen ODER must-have definieren und auswählen ODER ... am Ende fast egal, tun beide, was sie sollen.
 
Zuletzt bearbeitet:
Nein. Software läuft nur, wenn sie problemlos läuft. DAS ist damit gemeint. Und das ist keineswegs bei jedem Stück Software so ;)
Daß OPNsense mal 1 Jahr stressfrei durchlaufen kann, das ist mir halt neu jetzt. Hab das bisher anders gehört. Sorry...

Ich hab mich am Anfang in beide Richtungen umgeschaut und das einzige was ich zu 2.4.5-p1 fand (ich, wahrscheinlich wirds mehr geben (?)) war, daß es schon toll wäre, wenn man endlich VPN mit AES-NI nutzen könnte. Und PHP könnte mal weg, weil... es halt PHP ist und dann könnte das mal weg (den Part hab ich zugegeben aber nicht verstanden) 😉
Daß OPN eine viel aktivere Community hat und auch Updates viel öfters kommen, hat mich irgendwie vorerst abgeschreckt.

p.s.:
Es ist auch defacto überhaupt nichts abgekündigt bei pfSense.
 
Zuletzt bearbeitet:
Auch schön ich bin pünktlich zum release von 2.5 auf Opnsense gewechselt weil mich das UI von PF nur noch genervt hat :rolleyes2:
Und wo ist das von OPNSense jetzt „besser“ ? Das Argument hätte noch bei pfSense 2.0 gezogen, das war noch altbacken und von m0n0wall abgekupfert.

Mit dem Update auf 2.5 hats mir den pf zerpflückt. Keine States mehr, weil er sich aufgeregt hat, das er angeblich kein v6 Gateway hätte. Routingtabelle hatte eine Defaultroute zu fe80::1 mit WAN Interface, aber er störte sich daran und weigerte sich gänzlich, den Betrieb fortzusetzen. Auch statisch definierte v6 Subpräfixe mag er nicht so, da muss man dann plötzlich den Range im DHCPv6 vollständig angeben...also IPv6 scheint für manche FWs immer noch etwas Neuland zu sein.
 
Mir gefällt das Aufgeräumte UI von Opnsense deutlich besser als das noch immer Altbackende bei Pfsense. Außerdem die größere auswahl an Plugins und erweiterungen.

IPv6 nutze ich konsequent überhaupt nicht. Mein ISP nutzt es nicht und selbst auf der Fritzbox 7590 bei meiner Mutter lief das Internet der Telekom nicht flüssig mit IPv6 , erst nach deaktivierung war es ertragbar.
 
Wie macht ihr denn eure Updates? - bis Dato hab ich von der VM meist vorher einen Snapshot gemacht - und genau das 1x wo ich keinen hatte, ging das Update in die Hose und ich hab neu aufgesetzt...
aktuell überlege ich, ob ich mein "altes" Board nicht wieder reaktiviere und dann einen HA-Cluster fahren soll - brauchen tuts das nicht, aber eine Wartung am VM-Host wäre halt einfacher, weil kein Ausfall des Internet für die Familie...
Aktuell hab ich aber auch keine Plugins drin, nur normales NAT und eben die FW-Regeln für die 4 Netze - LAN(Home)/DMZ/LAB/Gast
 
Wie macht ihr denn eure Updates? - bis Dato hab ich von der VM meist vorher einen Snapshot gemacht - und genau das 1x wo ich keinen hatte, ging das Update in die Hose und ich hab neu aufgesetzt...
aktuell überlege ich, ob ich mein "altes" Board nicht wieder reaktiviere und dann einen HA-Cluster fahren soll - brauchen tuts das nicht, aber eine Wartung am VM-Host wäre halt einfacher, weil kein Ausfall des Internet für die Familie...
Aktuell hab ich aber auch keine Plugins drin, nur normales NAT und eben die FW-Regeln für die 4 Netze - LAN(Home)/DMZ/LAB/Gast
Via Console, wohl aber eher Geschmacksache.
 
Wie macht ihr denn eure Updates? - bis Dato hab ich von der VM meist vorher einen Snapshot gemacht - und genau das 1x wo ich keinen hatte, ging das Update in die Hose und ich hab neu aufgesetzt...
aktuell überlege ich, ob ich mein "altes" Board nicht wieder reaktiviere und dann einen HA-Cluster fahren soll - brauchen tuts das nicht, aber eine Wartung am VM-Host wäre halt einfacher, weil kein Ausfall des Internet für die Familie...
Aktuell hab ich aber auch keine Plugins drin, nur normales NAT und eben die FW-Regeln für die 4 Netze - LAN(Home)/DMZ/LAB/Gast
So wie du.
Snapshot -> Update -> Bei Fehlschlag zurücksetzen auf Snap
Zusätzlich gibt's integriert und (noch?) kostenlos: Services -> Auto Configuration Backup

Damit kannst du täglich dein Backup automatisch zu PFSense auf die Server schieben und das im Worst-Case (Snapshot vergessen / SSD hat sich verabschiedet) zurückspielen. PFSense installieren -> Auto Config Backup einrichten und zurückspielen -> fertig. Geht auch sehr schnell.
 
ach, das Config-Backup is ja nicht das Problem ;) - eher bei so einer VM die passende Zuordnung der Interfaces - hatte ja gottseidank auch erst einmal den Fall.
 
ach, das Config-Backup is ja nicht das Problem ;) - eher bei so einer VM die passende Zuordnung der Interfaces - hatte ja gottseidank auch erst einmal den Fall.
Ja gut, das stimmt. Das ist manchmal der helle Wahnsinn, da habe ich auch schon Ewigkeiten mit verbracht.

Machst du kein automatisiertes Backup von deiner PFSense VM bspw. mit VEEAM? Damit ist das Zurückspielen ja auch easy.
 
@home? - nope - ich mach ein Backup, wenn ich die Config geändert hab.
daher ja die Überlegung, ggf. einen Aktiv-Aktiv-cluster einzurichten - mit einer VM und einer Hardwarebüchse... - wobei ein aktiv-passiv @home auch reichen würde ;)
 
Ich habe jetzt auch nochmal den Versuch von 2.4.5 auf die 2.5.0 gewagt.

Aber happy bin ich nicht wirklich.
Habe nen Grandstream WP820 VOIP Telefon...Unter 2.4.5 NIE Probleme gehabt mit der Registrierung meines Sipgate Accounts.

Jetzt:
Gerät ist registriert für einige Stunden und plötzlich: Keine Registrierung mehr möglich!
Und der Firewall-Log der PFSense wird geflutet mit: "Default deny rule IPv4"

Wie bekomme ich das in den Griff? Neustart beseitigt das Problem, aber das kann keine Lösung alle paar Stunden sein.
Firewall Regel für das Endgerät hilft auch nicht...Und da es schon mit der alten Version funktionierte, müssten die auch weiterhin so passen.
 
Zuletzt bearbeitet:
Schöner Einblick in die Arbeitsweise von Netgate, macht mir persönlich wenig Hoffnung für pfsense und vor allem mehr Hunger auf OPNsense:

Begonnen wurden die Arbeiten an dem Wireguard-Port für FreeBSD vor etwa einem Jahr durch Matthew Macy, der dies für das Unternehmen Netgate umgesetzt hat, das wiederum Hauptsponsor der Firewall-Distribution Pfsense ist. Die so entstandenen Arbeiten sind letztlich Ende November 2020 größtenteils in FreeBSD gelandet.


Laut Donenfeld scheiterten dessen Versuche jedoch, mit den dafür Verantwortlichen in Kontakt zu treten. Der Code des Ports ist letztlich dennoch in FreeBSD importiert worden und der zuständige Entwickler hat sich anderen Projekten zugewendet. Wohl nur durch Zufall ist Donenfeld dann vor Kurzem erneut auf den Port aufmerksam geworden.


In der anschließenden Diskussion wurde dann wohl schnell klar, dass der bestehende Code grundsätzlich überarbeitet werden musste, was Donenfeld gemeinsam mit dem FreeBSD-Entwickler Kyle Evans sowie mit Matt Dunwoodie umsetzte, der für den OpenBSD-Port von Wireguard zuständig war.

Der zuvor in FreeBSD importierte Code war demnach von extrem schlechter Qualität. "Es gab wahllose Sleep-Aufrufe, um Race Conditions zu 'reparieren', Validierungsfunktionen, die nur True zurückgegeben haben, katastrophale kryptografische Schwachstellen, ganze Teile des Protokolls, die nicht implementiert wurden, Kernel-Panics, Umgehungen der Sicherheitsfunktionen, Überläufe, wahllose Printf-Anweisungen tief im Kryptocode, spektakulärste Buffer-Overflows und die ganze Litanei schrecklicher Dinge, die schief gehen, wenn die Leute nicht aufpassen, wenn sie C-Code schreiben".


Darüber hinaus hat der ursprüngliche Port auf FreeBSD einfach 40.000 Zeilen optimierten Kryptocode aus dem Linux-Kompatabilitätsmodul kopiert. Dieser sei aber nicht richtig integriert worden und mit einem Labyrinth aus Ifdef-Anweisungen verschränkt gewesen. Die drei beteiligten Entwickler haben den Code nun in gut einer Woche komplett überarbeitet und dabei im Prinzip wohl fast vollständig neu geschrieben. Lediglich die auch zuvor schon aus OpenBSD übernommenen Teile bleiben dabei unverändert.


Unabhängig von dieser Diskussion hat das Pfsense-Projekt bereits Mitte Januar eine Vorschau auf Wireguard in Pfsense 2.5 veröffentlicht, die noch auf dem alten FreeBSD-Code basiert, den Donenfeld und seine Mitstreiter nun ersetzt haben. Der Code ist dann letztlich auch mit Pfsense Plus 21.02 und mit Pfsense CE 2.5 Mitte Februar stabil veröffentlicht worden. Ob das Pfsense-Team nun seinen Code gegen den neuen FreeBSD-Code austauscht, ist derzeit noch nicht bekannt.
 
Schöner Einblick in die Arbeitsweise von Netgate, macht mir persönlich wenig Hoffnung für pfsense und vor allem mehr Hunger auf OPNsense:
Die Konzentrieren sich afaik gerade auf TNSR. Bin das auch noch am Testen...eigentlich Schade, bevor es OPNSense gab war pfSense richtig gut, die Entwickler haben noch eher auf die Community gehört und Vorschläge eingearbeitet und das System war einfach rockstable. Seit 2.5 wars das wohl...hatte mit dem Update von 2.4.5 auf 2.5 auch erhebliche Probleme mit der Erzeugung von IPv6 Default-Routen und pf im Allgemeinen.
 
Gruselig. Leider wissen wir nicht(?), welchen Code Opnsense für ihr wireguard Plugin nutzt? Da früher verfügbar als bei pfsense, vermutlich eher den OpenBSD Code?
 
Ich Versuche gerade zwei Kisten bei uns auf 2.5 upzudaten... Ebenfalls gruselig. Richtig vertrauen habe ich da nicht rein... Muss mal noch etwas testen, bevor ich das in den Produktiv Status gebe.... Man man...

Aber die OPNSense hat es bei mir auch schon zweimal dahingerafft... Hab echt bedenken, das sowas ähnliches später im Produktiv Betrieb auch passiert...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh