OPNsense Forum
International Forums => German - Deutsch => Topic started by: Helge on May 05, 2017, 01:42:09 pm
-
Hallo zusammen,
seit der Aktualisierung auf OpnSense 17.1.6 funktioniert Xauth nicht mehr. Das Anlegen eines neuen Phase 1 Vorschlag scheitert mit der Meldung "Die folgenden Eingabefehler wurden entdeckt: Das Feld Zertifizierungsstelle ist erforderlich" s.Bild. Würde ich ja gerne angeben, aber dieses Feld verschwindet wenn man die Authentifizierung auf Mutual RSA + Xauth stellt.
Des weiteren werden die Firewallregeln vom IPSec Interface ignoriert. Nur eine any -> any Freischaltung funktioniert.
-
Auch wenn mich dieses Problem jetzt nicht betrifft, gibt mir die gesamte "Politik" der OPNsense-Updates echte Rätsel auf. Ist ja nicht der erste Bug seit 17.1...
So mancher hier mag sich ja über pfsense und deren "Zukunftsvisionen" auf- bzw. erregen. Aber im pfsense Lager ist die 2.4 und damit FreeBSD11 immer noch nicht final. Evtl. auch aus gutem Grund!
Justmy2cent
Gruß
Dirk
-
Ich habe das Vertrauen in OpnSense verloren. Es wird nur am "Unterbau" geschraubt, aber die ganzen Fehler werden nicht angegangen. Im Gegenteil, es kommen zu jedem Update neue dazu. Ich bin in der produktiven Umgebung zurück zu PFSense und habe nur noch in der Testumgebung eine OpnSense. Ich hatte es einfach satt jede Nacht von Icinga raus geklingelt zu werden, nur weil neue Updates eingespielt wurden, nach denen wieder was nicht funktioniert.
Meiner Meinung nach müsste eine grundlegende Entscheidung getroffen werden. Einstellung aller Neuerungen an OpnSense und nur noch Bugs bearbeiten. Ich glaube, damit hat man gut 2 Jahre zu tun.
Mir persönlich ist es doch egal ob FreeBSD11 oder PHP7 läuft, entscheidend ist doch was "hinten raus kommt" und da kommt mir OpnSense langsam wie ein Trümmerhaufen vor.
-
Hi Helge,
https://github.com/opnsense/core/commit/4570776
# opnsense-patch 4570776
Die Qualität von FreeBSD können wir leider nicht beeinflussen.
Grüsse
Franco
-
Die Qualität von FreeBSD können wir leider nicht beeinflussen.
Hallo Franco,
ich glaube dass das auch niemand hier vom Entwicklerteam erwartet!!!
Ich gehe mal davon aus, dass das Gros der OPNsense-User froh und dankbar ist, dass es eine echte Alternative zu pfsense gibt. Nur ist m.E. neben der Sicherheit vor allem die Stabilität einer Firewall entscheidend.
Ich stimme daher Helge 100%ig zu!
Evtl. hätte das Entwicklerteam etwas auf die Bremse treten sollen und die 17.1 weiter auf FreeBSD 10.3 belassen sollen um den Unterbau/FreeBSD noch etwas reifen zu lassen. Ich denke einfach, dass Ihr Euch mit dem halbjährlichen raushauen von Major-Releases keinen gefallen getan habt. So etwas erzeugt einfach nur den Druck dann auch zum Termin was abliefern zu müssen!
Trotzdem glaube ich weiter an das Projekt an sich und werde es im Rahmen meiner (bescheidenen) Möglichkeiten weiter unterstützen!
Gruß
Dirk
-
Hi Dirk,
> Nur ist m.E. neben der Sicherheit vor allem die Stabilität einer Firewall entscheidend.
Das kommt ganz auf die Anforderungen an. Um so höher und professioneller die Anforderungen desto schwieriger ist das Kriterium der Stabilität zu erfüllen. Um so höher und professioneller die Anforderungen desto weniger kann ein reines Open Source Projekt mithalten. Aus gutem Grund.
Stabilität kann für uns nicht sein weniger Updates herauszugeben, selbst dann hätten wir die Fragen was ist sicher, was ist stabil, was wird benötigt, was kann warten. Auf der anderen Seite: der Nutzer darf entscheiden wann, wo und wie er updated. Er ist frei und ungezwungen. Dafür gibt es den Vulnerability-Scanner. Pakete können gesperrt werden oder Updates rückgängig gemacht werden. Einen Mehraufwand beim Aggregator zu suchen wenn man anforderungsspezifisch agieren kann pro Installation ist das eigentlich besser für die Skalierung, oder sehe ich das falsch?
Zumindest gibt es mit allen offenen Quellen sowie auch opnsense-update, opnsense-patch, opnsense-revert und opnsense-bootstrap Mittel und Wege den Status Quo wieder herzustellen. An einem gewissen Punkt muss jedem klar sein: dies ist keine Managed-Community, sondern eine Do-It-Yourself-Community.
> Ich stimme daher Helge 100%ig zu!
Ich generell nicht. Ich sehe:
> Es wird nur am "Unterbau" geschraubt, aber die ganzen Fehler werden nicht angegangen.
Ich entziffere:
> Es wird nur daran gearbeitet was mir egal ist, aber meine ganzen Fehler werden nicht angegangen.
Es ist auch nicht effektiv über eine solch verdeckte Haltung zu argumentieren. Da werde ich mir auch nicht die Finger daran verbrennen. :)
Im Forum werden Fehler kommuniziert. Das war so, das wird auch immer so sein. Ich sehe da keinen Ausweg. Wer hier nach Antworten sucht wird manchmal enttäuscht. Wer sich von der Enttäuschung mitreißen lässt und keinen Ausweg sucht wird dann auch nicht belohnt. Linux ist toll. pfSense auch. Warum verbittern? Entweder die Community ist es wert oder nicht. Gleiches Thema wie DIY oder Managed vorher.
> Evtl. hätte das Entwicklerteam etwas auf die Bremse treten sollen und die 17.1 weiter auf FreeBSD 10.3 belassen sollen um den Unterbau/FreeBSD noch etwas reifen zu lassen.
Und dann? Ein Jahr später auf FreeBSD 11.1, welches die gleichen systematischen Probleme hat? Probleme die wir nach 1,5 Jahren ausgraben und bis heute nicht 100% gefixt sind dort? Ein klitzekleines Beispiel eines Bugs aus FreeBSD 10.3 und 11.0, mit dem wir bis Januar 2017 kämpfen mussten.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211219
Leider ist es so, dass 10.1 die beste FreeBSD Version war die wir hatten. 10.2 hatte neue Probleme. 10.3 auch. Jetzt 11.0. Einige dieser Probleme sind ohne große Show für die Community behoben wurden. So viel zum unspektakulären Unterbau. So sollte es sein...
> Ich denke einfach, dass Ihr Euch mit dem halbjährlichen raushauen von Major-Releases keinen gefallen getan habt.
Ob "wir" alle 6 Monate oder 12 Monate oder 24 Monate eins auf den Deckel bekommen ist mir persönlich egal. :)
17.7 wird aller Voraussicht auf FreeBSD 11.0 basieren, die meisten Änderungen der Entwicklungsversion sind schon in 17.1.x eingeflossen. Vielleicht lassen wir auch einmal ein 11.x aus. Wer weiß. ES ist zu vermuten, dass der "Wechsel" sehr unspektakulär wird. Vielleicht sogar stabil.
Am Ende ist das Warten aus Gründen der Stabilität weniger Aufwand für Nutzer, aber mehr Aufwand für Entwickler. Das bringt mich wieder zurück dazu, dass niemand dann updaten muss wenn Updates vorhanden sind. Und der Möglichkeit eine langfristige Balance zwischen beiden Varianten zu finden.
Wie viel hat sich in 2 Jahren getan für diese Balance? Viel. Aber... Hand auf's Herz, wer merkt denn wenn wir konservativ sind? Wer hat gemerkt, dass wir mit OpenVPN 2.4 ein paar Monate gewartet haben? Und wer würde sofort schreien wenn wir es nicht hätten? :)
Der Crash Reporter und Twitter leuchten rot wenn etwas fundamentales schief läuft. Beides passiert eher selten. Wenn es passiert gibt es Hotfixes, zuletzt für Let's Encrypt in 17.1.5. Wie verlässlich ist der Prozess des Firmware Updates selbst?
Es ist schwer das ganze objektiv zu beleuchten wenn man nur sieht was bei einem selbst nicht funktioniert und sich dann vielleicht auch nichts bewegt.
> Trotzdem glaube ich weiter an das Projekt an sich und werde es im Rahmen meiner (bescheidenen) Möglichkeiten weiter unterstützen!
Das freut mich zu hören. Kann nur besser werden in der Zukunft sofern wir nicht aufhören daran zu glauben. :)
Grüsse
Franco
-
Am Ende ist das Warten aus Gründen der Stabilität weniger Aufwand für Nutzer, aber mehr Aufwand für Entwickler. Das bringt mich wieder zurück dazu, dass niemand dann updaten muss wenn Updates vorhanden sind. Und der Möglichkeit eine langfristige Balance zwischen beiden Varianten zu finden.
Wie viel hat sich in 2 Jahren getan für diese Balance? Viel. Aber... Hand auf's Herz, wer merkt denn wenn wir konservativ sind? Wer hat gemerkt, dass wir mit OpenVPN 2.4 ein paar Monate gewartet haben? Und wer würde sofort schreien wenn wir es nicht hätten? :)
Der Crash Reporter und Twitter leuchten rot wenn etwas fundamentales schief läuft. Beides passiert eher selten. Wenn es passiert gibt es Hotfixes, zuletzt für Let's Encrypt in 17.1.5. Wie verlässlich ist der Prozess des Firmware Updates selbst?
Es ist schwer das ganze objektiv zu beleuchten wenn man nur sieht was bei einem selbst nicht funktioniert und sich dann vielleicht auch nichts bewegt.
Man muss hier auch anmerken, dass wir immer auch Versionen haben, mit denen man neue Features vorab testen kann.
So ist es zum Beispiel möglich, dass wir Vorabversionen raus geben und somit die Möglichkeit wahrnehmen, dass Bugreports bearbeitet werden können, bevor die Änderung für stable freigegeben wird. Wenn es keine Tester dafür gibt, wird der Code nur intern und damit ggf. unter "Laborbedingungen" getestet (ist mir auch schon öfter passiert).
OPNsense ist ein OPEN SOURCE PROJEKT, das bedeutet es lebt von folgenden dingen:
- Entwicklern die das Beruflich oder in der Freizeit machen
- Benutzern, die konstruktives* Feedback geben
- sehr viel Kommunikation nach innen und außen
Ein Open Source Projekt gibt in der Regel niemals Garantien ab, dass etwas sicher funktioniert**, es ist aber im Interesse der Entwickler, dass es das tut. Es steht auch jedem frei, selbst einen Patch ins richtige Projekt beizutragen. Ich schreibe Patches weil es mir freude bereitet, ich etwas davon habe (kann es selbst nutzen und es ist so optimiert, dass es genau auf meinen use case passt), andere das auch nutzen können und auch verbessern (siehe z B. quagga plugin) können. Wenn jemand mein Plugin nicht mag, kann er es nicht nutzen, verbessern oder einfach trotzdem so nehmen wie es ist (und ggf. das Problem in einem Ticket beschreiben).
* man sollte den Fehler reproduzieren oder fixen können oder man sollte das Produkt sinnvoll für neue Bereiche erweitern können
** Einfach mal eine gängige Open Source Lizenz durchlesen
-
IPsec/Xauth ist nicht kaputt... ein Neustart wird benötigt in dem Fall. Gestern gab es ein Ticket mit Log-Schnipsel, die Analyse hat wenige Sekunden gedauert. ;)
https://github.com/opnsense/core/issues/1625
-
Bringt aber nichts, wenn man wie ich, zur Fehlereingrenzung die alten Einträge löscht und neu anlegt. Dann hat man nicht die Möglichkeit die Zertifizierungsstelle auszuwählen.
Vermutlich funktioniert das nur wenn man die alten Einträge lässt und OpnSense gleich neu startet.
-
Dafür gibt es System: Configuration: History.
Grüsse
Franco
-
Ich verbrenn mir genauso ungern an Grunsatzdiskussionen die Finger wie Franco ;) aber wie ist das zu verstehen:
"Am Ende ist das Warten aus Gründen der Stabilität weniger Aufwand für Nutzer, aber mehr Aufwand für Entwickler. Das bringt mich wieder zurück dazu, dass niemand dann updaten muss wenn Updates vorhanden sind. Und der Möglichkeit eine langfristige Balance zwischen beiden Varianten zu finden."
Natürlich bin ich nicht gezwungen dazu. Keinesfalls. Aber geschätzte OpenSource Philosophie hin oder her - wenn es Bugs oder Security Gründe gibt, dass ich auf eine neue Version updaten sollte - dann kann ich schlecht sagen: Oh bspw. 16.7 lass ich noch gut sein und bleib auf 16.1, weil das ist noch nicht so gut abgehangen und die Security Fixes lass ich bleiben. Und um das bleiben zu können, müssten ja alte (T-2? T-3?) alte Versionen ebenfalls gepatcht werden, damit man ruhigen Gewissens auf der alten Version bleiben kann. Ich glaube kaum, dass das dann für die Entwicklungsressourcen besser wäre, oder irre ich mich da?
Das ist glaube ich (?) auch der Kern von dem was Dirk schreibt. Ich update ja nicht zwangsläufig um "the latest and greatest" an Software zu bekommen, sondern eben um ein aktuelles OS/System zu haben ohne (bekannte) Lücken. Und dann auf dem Vorgänger oder Vorvorgänger zu bleiben aus Stabilitätsgründen ist bei einem System, dass ja Sicherheit bringen soll irgendwie ein ziemlich diamtraler Ansatz.
-
Wenn ich Open Source einsetze, dann wäge ich ab:
Erfüllt die Software im letzten Stand alle Laufzeitkriterien für mein Umfeld?
Ja, dann fertig.
Nein, dann verwende ich eine ältere Version, ggf. Bug Report wenn es wichtig ist.
Kann ich aus sicherheitstechnischen Bedenken nicht die ältere Version einsetzen, muss ich auf eine geeignete alternative Ausweichen.
Ich finde es fatal wenn nur gefordert wird. Habe noch nicht mal Rückmeldung bekommen ob die beiden gemeldeten Probleme in diesem Thread beseitigt wurden, um die sich offensichtlich gekümmert wurde.
Ansonsten gilt: FreeBSD 11.0 ist FreeBSD 11.0 egal wo es früher oder später eingesetzt wird. :)
Grüsse
Franco
-
Kann ich aus sicherheitstechnischen Bedenken nicht die ältere Version einsetzen, muss ich auf eine geeignete alternative Ausweichen.
Ich finde es fatal wenn nur gefordert wird. [...]
So ist es auch - im Open Source bereich gibt's selten "Nebenläufigkeiten", es gibt eine aktuelle Version und ggf. aktuelle Testbuilds. Alte Versionen werden höchstens bei ganz großen Projekten betreut, wo entsprechend Manpower vorhanden ist (Linux- und BSD-Distributionen, große Frameworks etc.).
@franco: So ein Problem hab' ich im Moment auch - Mein ganzes Feedback im Routing-Plugin (Quagga) kommt von Michael. Das macht es schwierig wirklich komplett stabiles Release bauen, weil ich nur zwei Tests hab (das Setup von mir + das von Michael wenn er Zeit dafür hat).
MfG
Fabian
-
> Erfüllt die Software im letzten Stand alle Laufzeitkriterien für mein Umfeld?
> Nein, dann verwende ich eine ältere Version, ggf. Bug Report wenn es wichtig ist.
Auf alter, unsicherer Version bleiben ist im Business Umfeld eher tödlich für einen Dienstleister. Wenn dann tatsächlich was passiert und der Kunde hinterfragt warum, ist man geliefert.
> Kann ich aus sicherheitstechnischen Bedenken nicht die ältere Version einsetzen, muss ich auf eine geeignete alternative Ausweichen.
Und was wäre das dann?
> Ich finde es fatal wenn nur gefordert wird. Habe noch nicht mal Rückmeldung bekommen ob die beiden gemeldeten Probleme in diesem Thread beseitigt wurden, um die sich offensichtlich gekümmert wurde.
Nicht falsch verstehen. Ich fordere hier gar nichts. Ich fand nur die Aussage "man kann dann die alte Version ja länger einsetzen" ein wenig mißverständlich. Wenn ich weiß, dass bspw. 16.x weiter upgedated wird wegen Sicherheitslücken - ja dann kann ich die weiter einsetzen. Wenn nicht, bin ich quasi "genötigt" auf die neue Version zu gehen, die mir ggf. Probleme macht um weiter die Produktsicherheit und die meines Netzes das ich damit sichere nicht zu gefährden. Für privat o.ä. mag das dann ein gangbarer Weg sein, aber gerade wenn ich an Business Umfeld denke, ich das eben kein gangbarer Weg. Und da mir immer wieder gesagt wurde und wird, dass opnSense auch auf dieses Feld gerne zielt, fand ich den Satz ziemlich irreführend.
@fabian: Natürlich ist es ein Problem sowohl der Manpower als auch des Testumfelds. Nur wenn ich dann hinterfrage bzw. positiv kritisiere (mir liegt es fern einen Flamewar oder sonstwas zu starten), ob bspw. die momentane Vorgehensweise mit fixen Releaseterminen etc. sinnvoll ist, solange man weder die Manpower noch die Userbase für breites Testing hat, und ich lese dann, dass das aber doch gut so ist, dann hege ich da doch Zweifel an der Aussage.
> Ich finde es fatal wenn nur gefordert wird. Habe noch nicht mal Rückmeldung bekommen ob die beiden gemeldeten Probleme in diesem Thread beseitigt wurden, um die sich offensichtlich gekümmert wurde.
Das ist natürlich erst recht schade, dass dann erst gefragt wird und dann so wenig Feedback kommt.
Wie gesagt mein hinterfragen ist nicht böswillig oder Streiterei, aber wir evaluieren gerade opnSense auch für diverse Kunden und da es dabei meist Firmenkunden sind, halte ich das gesagt eher (auch für uns) dann für bedenklich. Was nicht heißt, dass wir - und ich selbst - nicht möchten, dass das Projekt besser wird. Ich habe gerade eine Test Appliance freibekommen, die ich jetzt gern mit opnSense bespaße und rückmelde was ich kann. :)
Gruß
-
> Erfüllt die Software im letzten Stand alle Laufzeitkriterien für mein Umfeld?
> Nein, dann verwende ich eine ältere Version, ggf. Bug Report wenn es wichtig ist.
Auf alter, unsicherer Version bleiben ist im Business Umfeld eher tödlich für einen Dienstleister. Wenn dann tatsächlich was passiert und der Kunde hinterfragt warum, ist man geliefert.
> Kann ich aus sicherheitstechnischen Bedenken nicht die ältere Version einsetzen, muss ich auf eine geeignete alternative Ausweichen.
Und was wäre das dann?
Hier hör ich jetzt auf, weil: Absatz 1 von dir entspricht meinem Absatz 2. Leider lässt du dies links liegen als hätte ich nicht darauf geantwortet und stellst in Bezug zu Absatz 2 dann lieber die Gretchenfrage. ;)
Grüsse
Franco
-
Auf alter, unsicherer Version bleiben ist im Business Umfeld eher tödlich für einen Dienstleister. Wenn dann tatsächlich was passiert und der Kunde hinterfragt warum, ist man geliefert.
Diese Art von Dienstleisteren mit solchen Kunden verlangen aber einen Stundensatz von mind. 150 EUR und haben Serviceverträge von mehreren 100 EURs. Ich bezweifle ganz stark dass hier so ein junges Projekt produktiv eingesetzt wird. Wir machen hier z.B. Cisco und Sophos, für unwichtige bzw. voll redundante Systeme kommt eine pfSense. Wir evaluieren auch gerade OPN, und das tolle ist, man kann sich selbst beteiligen.
Habe bei pfSense bzgl. Quagga gefragt da ich OSPF und BGP benötige. Da bekam ich ein plumpes "geht nicht" (ein virtueller Arschtritt war glaub ich auch noch dabei) ::)
Hier kann ich mich einfach beteiligen und Code beisteuern und ich bin echt der absolute no-brainer was programmieren betrifft. Dafür gibt es dann einige die sich auskennen, das reviewen und testen. Klar kann sich da der Fehlerteufel einschleichen, aber hey, mit ein bisschen Zeit und Geduld kommt da jeder rein und ich hab jetzt alle Möglichkeiten. Wenn ich z.B. ne GUI für Softether will programmier ich schnell was, wenn ich nicht weiter komme stell ich ne dumme Frage und fertig. Und das geht für alles was im Repo ist, und wenn nicht stellt Franco das pkg ein (sofern es Sinn macht).
Ich arbeite schon über 15 Jahre in dem Business, ich hab sowas noch nie gesehn! Da ist einiges an Potential da.
Für mich ATM:
Kunde mit Ansprüchen: Cisco/Sophos
Kunde mit kleinem Geldbeutel: OPN, mit der Ansage dass es halt nicht commercial ist
Was die Kurve zeigt definitiv nach oben und je mehr mitmachen desto steiler/geiler wird sie 8)
Nicht falsch verstehen. Ich fordere hier gar nichts. Ich fand nur die Aussage "man kann dann die alte Version ja länger einsetzen" ein wenig mißverständlich. Wenn ich weiß, dass bspw. 16.x weiter upgedated wird wegen Sicherheitslücken - ja dann kann ich die weiter einsetzen. Wenn nicht, bin ich quasi "genötigt" auf die neue Version zu gehen, die mir ggf. Probleme macht um weiter die Produktsicherheit und die meines Netzes das ich damit sichere nicht zu gefährden. Für privat o.ä. mag das dann ein gangbarer Weg sein, aber gerade wenn ich an Business Umfeld denke, ich das eben kein gangbarer Weg. Und da mir immer wieder gesagt wurde und wird, dass opnSense auch auf dieses Feld gerne zielt, fand ich den Satz ziemlich irreführend.
Egal ob mit 6 Monatszyklus oder nicht, Fehler schleichen sich immer ein. Bei reinem opensource wahrscheinlich mehr wie bei kommerziell, aber dafür zahlt man ja auch nix! Und ich kann leider nicht an einer Hand abzählen wie oft schon was mit Sophos/Astaro war. Da wurde sogar mit Premium Support nicht auf meine Wünsche reagiert.
@fabian: Natürlich ist es ein Problem sowohl der Manpower als auch des Testumfelds. Nur wenn ich dann hinterfrage bzw. positiv kritisiere (mir liegt es fern einen Flamewar oder sonstwas zu starten), ob bspw. die momentane Vorgehensweise mit fixen Releaseterminen etc. sinnvoll ist, solange man weder die Manpower noch die Userbase für breites Testing hat, und ich lese dann, dass das aber doch gut so ist, dann hege ich da doch Zweifel an der Aussage.
Eine breite Userbase bekommst du nur wenn du viele Features und hier und da ein Alleinstellungsmerkmal hast. Das ist eher ein Henne-Ei-Problem. Stabile Software und warten bis User kommen oder hier und da ein Bug und dafür eine stetig wachsende Userbase? Wie du's machst is' verkehrt. ;D
-
Hallo zusammen,
die Diskussion ist sehr spannend und vieles was hier aufgeführt worden ist sicherlich auch nachvollziehbar und richtig. Dennoch glaube ich, dass es erforderlich ist, einige der Aspekte nochmals aus einer anderen Perspektive zu beleuchten.
Zunächst: was hier bei Opnsense geleistet wird ist in jeder Hinsicht hochgradig anerkennenswert und vor allem dem unermüdlichen Einsatz von nur wenigen aktiven Streitern zu verdanken, die neben der Entwicklung und Pflege der Plattform auch noch die gesamte Bedienung der Kommunikation stemmen. Der Output ist extrem effektiv und kompetent, dafür Chapeau und Gratulation. Auch ich werde im Rahmen meiner Möglichkeiten (die iW Test und Kommunikation von Findings bedeuten (bin leider kein php Experte ;))) nach Kräften weiterhin dazu beitragen!
Aus meiner Sicht muss man die Thematik abschichten: Zunächst mal die technische Sicht/die Erwartung:
Opnsense muss den Anspruch haben, produktiv einsetzbar zu sein. Diese Erwartung weckt das Projekt auf seinem Webauftritt und kommerzielle Angebote (Appliances, Service, ...) rund um Opnsense befeuern genau diese Erwartung. Produktiv meint hier, einmal konfiguriert sehen viele in Routern/FW ein 'eh da' System, was über Wochen und Monate einfach funktioniert und ohne signifikante Serviceunterbrechung gewartet werden kann. Schade finde ich, dass in der Diskussion der Eindruck entstehen könnte, dass man so etwas von einer Opensource Lösung, die durch eine Community getrieben wird, nicht realistisch erwarten darf. Diese Sicht teile ich nicht und es gibt genügend Beispiele, dass das nicht so ist. Opnsense hat bislang jedenfalls auch diese Erwartung hervorragend bedient.
Ein Router/eine Firewall hat aus meiner Sicht besondere Anforderungen an Stabilität und Sicherheit und unterscheidet sich dadurch auch von anderen Softwareprojekten. Das ist unabhängig von 'Opensource' oder 'Kommerziell' und gilt auch für Opnsense. Design und Roadmapentscheidungen müssen sich aus meiner Sicht zuallererst an diesen beiden Kriterien orientieren; neue Features müssen zur Not dann auch hinten anstehen. Ob Opensource oder Kommerziell, Ziel eines jeden SW Projekts sollte es sein, alles dafür zu tun, SW in hoher Qualität zu realisieren und möglichst fehlerfreien Code zu bauen (auch wenn es das absolut nicht gibt). Dieses Paradigma gilt für alle an der Bereitstellung der Lösung beteiligten Komponenten, also 'Unterbau' und 'Plattform', nur so kann das Gesamtergebnis stimmen. Eine Position 'für Fehler im Unterbau können wir nichts, das ist FreeBSD Sache' hilft da nicht, wenn es das eigene Ergebnis kompromittiert.
Technisch betrachtet gibt es ja bei FreeBSD die Möglichkeit, Releases zu verwenden, die mehrere Jahre gepflegt werden (selbst 10.3 RELEASE wird nach meinem Verständnis bis MINDESTENS Ende April 2018 mit Updates versorgt, wahrscheinlich sogar noch länger) und damit eine höhere Reife aufweisen sollten (das stimmt zwar nicht in allen Details, aber in vielen Bereichen). Den Tradeoff zu managen, wann man auf eine neue 'Unterbau'-Version wechselt und wann man neue 'Features' einbaut ist schwierig und ein ständiger Balanceakt.
Mit Release 17.1 hat Opnsense eine Vielzahl von Neuerungen gebracht, die über die letzten Releases von 16.7 und 17.1-BETAs vorbereitet wurden (Suricata, Sprachen, UI, ....). Gleichzeitig wurde aber auch der 'Unterbau' auf FreeBSD 11.0 upgedated, mit einer Reihe von unschönen Seiteneffekten wie Consoletreiber, Installations- und Updatethemen sowie unterschiedlichem Verhalten auf verschiedener HW usw. Gefühlt ist im Ergebnis in der Tat der Eindruck entstanden, daß das Major Release Upgrade auf 17.1 nicht so geschmeidig verläuft wie man es von vorherigen Releases kannte (ich selbst arbeite seit 15.1 auf 15.7 mit Opnsense). 17.1 stürzt im Betrieb bei mir häufiger ab als die Releases vorher. Das ist mein persönlicher Erfahrungswert, andere mögen da andere Erfahrungen haben. Ich frage mich, was kann ich beitragen, um den Zustand zu verbessern.
Das bringt mich dann zum zweiten Punkt: Was kann die Opnsense Community in ihrer heutigen Form denn realistisch leisten? War es vielleicht 'zuviel auf einmal' mit 17.1 auch den Unterbau zu wechseln? Fakt ist: Sichtbar contributen nicht vielmehr als eine Handvoll Leute regelmäßig zum Opnsense Code, unterstützt von einigen, die qualifiziert Fehler zurückmelden; fixen tun es dann aber wieder die gleichen Leute. Es ist aus meiner Sicht ein riesen Stretch, ein Projekt mit der Komplexität mit so wenigen zu stemmen und gleichzeitig auch noch zu versuchen den Link zur FreeBSD Community zu bilden und ganz viele HW Varianten zu unterstützen, Treiber, etc.. Ich halte es für schlicht unrealistisch in dem Setup die og Erwartung zu bedienen. Die Aktiven sind dadurch gezwungen, Kompromisse einzugehen und 'mutige' Entscheidungen zu treffen, um das Projekt nach vorne zu bringen. Das geht häufig gut, manchmal eben auch nicht.
Sprüche wie 'ich habe jetzt aber mal das Vertrauen verloren' bringen in der aktuellen Situation in der Sache gar nichts! Stattdessen würde ich mir wünschen, dass alle, die Erwartungen vor sich her tragen, darüber nachdenken wie sie denn AKTIV helfen können, das Projekt zu unterstützen und nicht einfach auf 'die Entwickler' - also 'Andere' aber nicht 'ich' verweisen. Ich bin fest davon überzeugt, dass Opnsense dies wert ist !!! :) :)
Vielleicht schaffen wir es ja alle zusammen, in ein Setup zu kommen, in dem eine stabile produktive Release auf vielleicht nicht der allerletzten Leading Edge Release stabil gepflegt werden kann und sich an den Releasezyklen von FreeBSD orientiert und sich eine zweite Release überlappend dazu mit den neuesten Features beschäftigt und leading edge Unterbau beschäftigt. Und vielleicht schaffen wir es ja sogar dann auch noch, dass sich eine weitere Gruppe mit Backports von Core Essentials beschäftigt, die einfach großes Interesse in produktiven Umgebungen geschaffen haben, bevor die Leading Edge Release produktionsreif ist.
Das erfordert aber einfach, dass mehr Leute aktiv mitmachen - anders wird es nicht funktionieren. Und es wäre schön, wenn möglichst viele dies als Appell auffassen würden, mitzumachen und einen Beitrag zu leisten.
In diesem Sinne
Br br
-
@Franco: Schade. Denn ich habe nichts ignoriert was du geschrieben hast, sondern hinterfragt. Wenn das eine "Gretchenfrage" sein soll, so be it. Wenn du eben selbst in den Raum stellst, dass ich dann ne Alternative brauche, dann stellt sich keine Gretchenfrage, sondern dann mache ich das vielleicht ein oder zweimal mit, danach bleib ich dann bei Alternativen. Und das finde ich an der Aussage und dem Umgang mit dem Thema schade.
Natürlich kann man sich beteiligen, es ist OpenSource etc. etc. das habe ich alles nicht in Abrede gestellt. Nur wenn ich das Projekt eben außer als Bastellösung (und das ist positiv gemeint) im privaten oder (sehr) kleinen Gewerbe einsetzen will, dann brauch ich als guter Dienstleister eine Rollback Strategie. Und da muss ich dem Post von mimug widersprechen, das machen NICHT nur Dienstleister die 150€ verlangen, sondern alle die das ganze ernst nehmen und ernsthaft gegenüber ihren Kunden betreiben. Denn einem Kunden behandle ich ehrlich und da gehört auch Offenheit dazu. Also kehre ich offene Bugs oder Security nicht unter den Teppich mit "muss man noch warten" etc. Nur weil etwas OpenSource ist, heißt das für mich nicht Bastellösung.
> Das ist eher ein Henne-Ei-Problem. Stabile Software und warten bis User kommen oder hier und da ein Bug und dafür eine stetig wachsende Userbase? Wie du's machst is' verkehrt.
Auch das sehe ich nicht. Wenn ich eben noch nicht die Userbase habe und auch die Entwicklerkapazität nicht, dann mache ich eben auch keine Releases mit festen Daten, gerade wenns Major Releases sind mit ziemlich großen Umbauten untendrunter (neues FreeBSD bspw.). Und da muss ich eben sagen, kam mir bei unseren Tests das ganze 17.1 Release ziemlich überhetzt vor. Selbst die angesprochenen großen Projekte wie Debian sagen da "when it's done" und das aus gutem Grund.
Genau das war meine Frage, ob das nicht mehr Sinn macht, als sich in die Erklärungen von oben zurückzuziehen (altes Release bleiben, zurückrollen, Alternative etc.). Das alles bräuchte man nicht, wenn das neue Release mehr Zeit hat zu reifen und nicht zum Termin raus muss, rollt es vielleicht auch einfach glatter als jetzt. Aber das mag mein Empfinden und Verständnis sein. Bevor das in irgendwelche Beschuldigungen ausartet was nicht meine Intention war, lass ich es an der Stelle ebenso bewenden mit meiner Anregung über das Release Modell (und Untersütztung der Vorgänger Version) nachzudenken. Mehr nicht :)
-
Natürlich kann man sich beteiligen, es ist OpenSource etc. etc. das habe ich alles nicht in Abrede gestellt. Nur wenn ich das Projekt eben außer als Bastellösung (und das ist positiv gemeint) im privaten oder (sehr) kleinen Gewerbe einsetzen will, dann brauch ich als guter Dienstleister eine Rollback Strategie. Und da muss ich dem Post von mimug widersprechen, das machen NICHT nur Dienstleister die 150€ verlangen, sondern alle die das ganze ernst nehmen und ernsthaft gegenüber ihren Kunden betreiben. Denn einem Kunden behandle ich ehrlich und da gehört auch Offenheit dazu. Also kehre ich offene Bugs oder Security nicht unter den Teppich mit "muss man noch warten" etc. Nur weil etwas OpenSource ist, heißt das für mich nicht Bastellösung.
Aber das ist doch super! Du bist ehrlich und bietest an:
Ein junges dynamisches Produkt mit viel Potential und das kostenfrei, oder ein die kommerzielle Lösung von XY.
Ich mache das auch öfters, je nachdem wie groß der Kunde ist.
Über kurz oder lang müsste sowas wie bei Redhat rauskommen. Eine freie Version mit Bleeding Edge (Fedora) und eine stabile und kommerzielle Version die sich die Rosinen aus dem Fedora pickt (RHEL).
-
Ein junges dynamisches Produkt mit viel Potential und das kostenfrei, oder ein die kommerzielle Lösung von XY.
Ich mache das auch öfters, je nachdem wie groß der Kunde ist.
Über kurz oder lang müsste sowas wie bei Redhat rauskommen. Eine freie Version mit Bleeding Edge (Fedora) und eine stabile und kommerzielle Version die sich die Rosinen aus dem Fedora pickt (RHEL).
Sorry,
aber was hat die 'Größe' eines Kunden damit zu tun, ob ich Ihme eine OpenSource- oder eine kommerzielle Lösung empfehle!?
Einzig die Anforderungen eines Kunden sollten die Lösung bestimmen. Wenn natürlich eine Interessent schon gleich mit der Anforderung 'Darf nichts kosten!' durch die Tür kommt, muss man Ihm eben erklären, warum so etwas eine völlig falsche herangehensweise ist. Zumal Opensource eben nicht 'kostenlos' bedeutet. So sind z.B. Filterlisten für den Webproxy sind i.d.R. nur bei privater Nutzung kostenlos (z.B. Shalla). Bei kommerzieller Nutzung muss oft eine Lizenz erworben werden.
Erstmal Anforderungen definieren!!!
So kann es eben durchaus sein, dass man kommerzielle und OpenSource gemischt nutzt. Um kleine Standorte anzubinden ist so eine *sense wirklich gut geeignet.
Für unser Unternehmen ist die *sense z.B. nicht geeignet, da wir auch den Bereich Anti-Spam auf der Appliance abgedeckt haben wollten und auch der Webproxy unseren Anforderungen nicht genügt (z.B. ACL abhängig von AD Usergruppen).
Gruß
Dirk
-
aber was hat die 'Größe' eines Kunden damit zu tun, ob ich Ihme eine OpenSource- oder eine kommerzielle Lösung empfehle!?
Kunde mit 1-10 MA -> Findet auch Fritzbox OK, wieso dann ein Produkt mit Lizenzgebühren
Kunde mit 100-300 MA -> Kritische Infrastruktur muss geschützt werden, darf gern was kosten
(das sind die eigenen Meinungen der Kunden).
-
@mimugmail
Da ist man dann als Berater gefragt!
Es gibt auch im Bereich < 20 PC Arbeitsplätze* durchaus kostengünstige kommerzielle Lösungen. Man muss halt dem Kunden vermitteln, welche Benefits er durch eine kommerzielle Lösung hat (z.B. professionelle AV- und Spamfiltermodule, aktuell gepflegte Kategoriesperren für den Webproxy, wöchentliches Reporting). Dann relativieren sich auch die Kosten für die jährliche Subscription.
Und bei jeder Lösung, egal ob Opensource oder kommerziell ist ohnehin die Kompetenz des umsetzenden Partners von entscheidender Bedeutung. :)
Gruß
Dirk
PS: Nein, ich verkaufe keine Firewalls. Davon hab ich bei weitem nicht genug Ahnung! Ich bin aber seit 20 Jahren im Bereich DMS und ERP unterwegs. Und da sind die Voraussetzungen oft ähnlich. Dem Einen Unternehmen mit 10 MA reicht eine Lexware, der Andere braucht SAP!
*Die Anzahl der Mitarbeiter hat nicht unbedingt etwas mit der Anzahl der PC-AP zu tun. Ich kenne Firmen mit ~ 200 MA, bei denen nur 5 MA an PC's sitzen!
-
Da kann ich Dirk nur beipflichten. Größe ist überhaupt kein Merkmal, es gibt auch große Häuser mit >100 Mitarbeitern, die mit 10MBit/s Leitungen herumgurken und kaum was machen genauso wie kleine agile Unternehmen mit <20 Leuten, die Gigabit Glasfaser haben und Proxy und Co einsetzen wollen. Beiden kann ich problemlos eine Sense anbieten für das was sie einsetzen wollen. Oftmals sind sogar schwergewichtige Pakete wie Content Filter etc. gar nicht wirklich notwendig, wenn man bspw. einen pfBlocker auf Layer 3 schon richtig konfiguriert, eine entsprechende IP Liste (mit aktiver Subscription) reinhängt und ab die Katze. Warum soll ich auch Deep Package Inspection machen, wenn ich solche Seiten gar nicht erst aufrufen kann? ;)
Und genau da ist man als Consultant, Specialist oder wie auch immer die hippen Bezeichnungen mitunter lauten gefragt, eben den Firmen zu verklickern "Hey natürlich könnt ihr <Firma> kaufen, habt Hardware X und Softwarelizenz Y als Kosten, aber ihr könnt das auch mit Sensen und angepasster Hardware machen! Da zahlt ihr Hardware + Integrationskosten durch die Firma."
Und bei den meisten, mit denen ich aus dem Umfeld gesprochen habe, ist eine Sense dann günstiger, selbst wenn sie monatlich noch nen Support oder Stundenkontingent einkaufen, weil es keine sinnbefreiten "Lizenzscheinchen" gibt, wo man eine Urkunde mit "+10 VPN Lizenzen" und Co bekommt. Das hat heute beim entsprechenden Berater gar nichts mehr mit "Kommerzielle Lösung" zu tun, sondern mit Support und Erfahrungslevel. Wenn der da ist und der Kunde das merkt, dann ist dem Wurscht ob da Cisco, Sophos oder *Sense draufsteht. Der will ja eh nur "dass es funktioniert".
-
Der will ja eh nur "dass es funktioniert".
Fast: da fehlt noch "und wenig kostet" ;)
-
Guten Abend,
Technisch betrachtet gibt es ja bei FreeBSD die Möglichkeit, Releases zu verwenden, die mehrere Jahre gepflegt werden (selbst 10.3 RELEASE wird nach meinem Verständnis bis MINDESTENS Ende April 2018 mit Updates versorgt, wahrscheinlich sogar noch länger) und damit eine höhere Reife aufweisen sollten (das stimmt zwar nicht in allen Details, aber in vielen Bereichen). Den Tradeoff zu managen, wann man auf eine neue 'Unterbau'-Version wechselt und wann man neue 'Features' einbaut ist schwierig und ein ständiger Balanceakt.
Das Thema ist über die Jahre immer schwieriger geworden. Mir scheint dass gern über (fehlende) Stabilität geredet wird, aber die Nachhaltigkeit bei der Debatte vernachlässigt wird.
Folgende erste These stelle ich in den Raum: wollen wir mit OPNsense langfristig am Ball bleiben, müssen wir kurz- und mittelfristig uns auf die Neuerungen der Projekte einlassen, die uns definieren, bzw. über die wir uns definieren.
Die zweite These wäre: OPNsense bietet freie und offene und uneingeschränkte Entwicklerwerkzeuge und Lizenzen mit denen man genau das bauen kann was man will wenn man das möchte, ohne wenn und aber, und wir sehen uns daher nicht in der Pflicht, die letzten Prozente zum perfekten Projekt/Produkt liefern zu müssen.
Das heißt nie dass jemand die Sicherheit weggenommen wird wie schon in den Raum gestellt wurde. Es ist eher das Gegenteil der Fall: die Weiterführung von Sicherheit kommt mit Einbußen in der Featureliste, ob nun gewollt, ungewollt, boshaft oder versehentlich.
Wir haben mit FreeBSD 10.0 angefangen. Das Update auf 10.1 war super. Mit 10.2 fingen die Probleme an. Mit 10.3 wurden es mehr. Der Trend hat sich mit FreeBSD 11 fortgesetzt. Ein Ende ist nicht in Sicht, aus Gründen die selbst ich nicht verstehe. Es scheint fast so als fehlt die Kernexpertise für Anwendungsfälle aus dem m0n0wall, pfSense, OPNsense Lager: werden diese Features nicht von den Trägern der FreeBSD-Entwicklung entsprechend kultiviert, trifft das in zunehmenden Maße eben m0n0wall, pfSense, OPNsense negativ.
Man könnte jetzt meinen man hätte auf FreeBSD 10.3 bleiben können, aber um da keine Debatte ad absurdum zu führen in der man dann fragt warum nicht auf 10.2 bleiben, warum nicht auf 10.1 bleiben, etc., bleiben 3 Möglichkeiten:
1. Die aktuelle Version halten. Das kann man 1x machen, vielleicht 2x, dann ist ein Jahr verloren. Ein Update auf eine neue Betriebssystemversion wird schwieriger und nötiger. Der Unmut der Community ist größer, wenn das alternativlose Update dann doch kommt nach längerer Wartezeit. Die Probleme woanders lösen sich nicht von allein, zumindest wenn man sieht wie sich FreeBSD wie eingangs erklärt entwickelt hat.
2. Auf die nächste Minor Version updaten. Bringt theoretisch: wenig neue Features, viele Fixes. Bringt praktisch: neue Fehler, wie gesichtet in 10.2 und 10.3.
3. Auf die nächste Major Version updaten. Bringt theoretisch: viele neue Features, viele Fixes. Bringt praktisch: viele neue Features, viele Fixes, neue Fehler.
Unter dem Strich ist selbst Option 3 kurzfristig besser als Option 2, mittel- und langfristig besser als Option 1. Es gibt hier keinen echten "Balanceakt" wenn wir über Nachhaltigkeit und OPNsense in 2-5 Jahren sprechen wollen. Ich weiß nicht ob wir das wollen, aber ich kann mir vorstellen, dass dies einige von uns erwarten? ;)
Dass es Bestrebungen gibt diesem "Teufelskreis" zu entkommen ändert nichts an der Tatsache, dass dies auch einige Jahre dauert und Verlust von Features mit sich bringt, weil Betriessystem X oder Y dies nicht unterstützt.
Es scheint so, als ob, egal was wir tun, um nicht still zu stehen immer einen Verschleißanteil tolerieren müssen.
Und dann kommt das Befreiende in Verbindung mit These 2: seit 2015 gibt es über uns (wieder) die Möglichkeit mit den Entwicklerwerkzeugen mit denen jeder schnell und zuverlässig das größte beste schnellste schönste und verlässlichste und sicherste Projekt bauen kann dass er oder sie sich wünscht. Einige Hersteller tuen dies in ihrer Nische. Es kann wirklich jeder der es versucht. Dann fehlt nur noch die tägliche Arbeit um es aktuell zu halten. :)
Grüsse
Franco
-
Hi Franco,
Dein Post beschreibt sicherlich einen validen Konflikt, den ich wie folgt adressieren würde:
Im Linuxlager gibt es für alle Deine drei zitierten Szenarien Distributionsbeispiele (Debian, Ubuntu, Redhat etc.) Und alle drei haben für verschiedene Anwendungsfälle ihre Stärken und natürlich auch Schwächen. FreeBSD ist ebenfalls ein General Purpose OS. So gesehen ist Opnsense ein sehr spitzes Applikationsgeschehen mit einer klar definierten aber eher schmalen Bandbreite an benötigten Funktionen des OS. Würde ich zB eine Firewallappliance auf Linux aufsetzen würde ich eher Debian wählen (seehhr alter (aber gewarteter Kernel) und weniger die neueste Ubuntu Release 17.04; genauso würde ich auch HW seitig nicht den letzten Schrei einsetzen (damit bin ich ja nun gerade selbst recht nett vor die Pumpe gelaufen, siehe https://forum.opnsense.org/index.php?topic=5063.0 und https://forum.opnsense.org/index.php?topic=4637.0)
Daher frage ich mich, was die WIRKLICH JETZT benötigten neuen Features von 11.0 sind die den Wechsel treiben. Nach meinem Verständnis könnten dies doch nur neuere NIC Treiber sein, ggf auch Updates im IP(v6) Stack oder neue Versionen bei IDS oä; PHP7 und andere Dinge gibts als Updates für 10.3 auch. War das Delta wirklich so groß (zB auch wenn man an die Realtek Treiber issues denkt etc.)? Aus meiner Sicht eher nicht.
Zwei Ansätze könnten hier vielleicht hilfreich sein
1.) Man könnte zB einen Wechsel des Unterbaus nicht gemeinsam mit einem Major Release durchführen sondern eher mittendrin, in der ersten Hälfte fokussiert man auf neue Features, in der zweiten Hälfte auf neuen Unterbau. Dann kann man die Zeitleiste mit der Freebsd Releaseroadmap syncen, die ja mW auch etwa im Jahrerythmus tickt
2.) Man pflegt eine stable Release auf einer älteren Unterbau Version mit minimalen Backports für die Produktion und fokussiert sich auf Bugfixes und die Integration von Sicherheitsupdates; Man hat eine progressive innovative Release und setzt diese erst später nach einer ausgiebigen Testphase und Stabilisierungsphase für produktive Zwecke ein. Mit der Übergabe in die Produktive Phase managed man die alte ab und stellt die Pflege ein, um den Aufwand zu minimieren. So hat man max. 2 Versionen 'in Arbeit'. Der Vorschlag wurde ähnlich auch schon gemacht ...
Für Modell 2 müssten wir sicherlich mehr aktive Mitarbeiter in der Community gewinnen. In jedem Fall brauchts die von Dir richtigerweise erwähnte professionelle Entwicklungsumgebung
Ich glaube im Grundsatz, dass eine stabile, sichere, produktiv eingesetzte und gepflegte Version dem Projekt mehr Reputation verschafft und vielleicht mehr Contributions von Firmen/Organisation/Personen triggern könnte, die diese einsetzen. In Summe könnte dies die Sache schneller voranbringen.
Br br
-
Guten Abend,
eine sehr interessante Diskussion.
Es würde mich interessieren, wer bei dem Einsatz einer OPNsense bislang einen Einbruch in ein System vermelden kann, der nicht auf einen unvorsichtigen USER/mangelhafte Konfiguration der Firewall/Dienste zurückzufüren ist.
Diese Frage stellt sich mir deshalb weil ich gerne ein Gefühl dafür hätte, was zwischen dem letzten Release, und sich aus Zwängen des praktischen Einsatzes ergibt/ergeben hat.
Anderst ausgedrückt, hätte mit dem letzten Release tatsächlich ein Einbruch (so denn stattgefunden) vermieden werden können? Und gibt es tatsächlich Kundenanforderungen/Hardwareneuerungen die explizit die Features des letzten Major-Releases, *NACH* der Antwort auf die vorhergehende Frage, einfordern?
Interessant sind für mich Antworten aus der Praxis - was theoretisch möglich ist und Wunschdenken aus dem Vertrieb, sind für mich an dieser Stelle weniger von Bedeutung.
stefan
-
Im Linuxlager gibt es für alle Deine drei zitierten Szenarien Distributionsbeispiele (Debian, Ubuntu, Redhat etc.) Und alle drei haben für verschiedene Anwendungsfälle ihre Stärken und natürlich auch Schwächen. FreeBSD ist ebenfalls ein General Purpose OS. So gesehen ist Opnsense ein sehr spitzes Applikationsgeschehen mit einer klar definierten aber eher schmalen Bandbreite an benötigten Funktionen des OS. Würde ich zB eine Firewallappliance auf Linux aufsetzen würde ich eher Debian wählen (seehhr alter (aber gewarteter Kernel) und weniger die neueste Ubuntu Release 17.04; genauso würde ich auch HW seitig nicht den letzten Schrei einsetzen (damit bin ich ja nun gerade selbst recht nett vor die Pumpe gelaufen, siehe https://forum.opnsense.org/index.php?topic=5063.0 und https://forum.opnsense.org/index.php?topic=4637.0)
Arch Linux ist toll. Da hat man immer nen neuen Kernel (nahezu unmodifiziert) mit den neuesten Treibern und da man in dem Bereich mehrheitlich in den core-Paketen bleibt, ist es auch ziemlich stabil. Außerdem hat man nftables ohne Backports, das System ist möglichst schlank, updates gehen reibungslos immer weiter, da es keine Release gibt und es setzt stark auf systemd.
IPFire verwendet übrigens meines Wissens nach Linux from Scratch.
nftables:
https://wiki.nftables.org/wiki-nftables/index.php/Main_Page
https://wiki.archlinux.org/index.php/nftables
Daher frage ich mich, was die WIRKLICH JETZT benötigten neuen Features von 11.0 sind die den Wechsel treiben. Nach meinem Verständnis könnten dies doch nur neuere NIC Treiber sein, ggf auch Updates im IP(v6) Stack oder neue Versionen bei IDS oä; PHP7 und andere Dinge gibts als Updates für 10.3 auch. War das Delta wirklich so groß (zB auch wenn man an die Realtek Treiber issues denkt etc.)? Aus meiner Sicht eher nicht.
Wenn man das nicht machen würde - sagen wir mal wir würden FreeBSD11 überspringen und danach kommt 12 - müssten weit mehr Änderungen gemacht werden, da die Änderungen von mehreren Releasesprüngen durchgeführt werden müssen. Da wäre dann vermutlich wirklich "Feuer am Dach", weil die Änderungen größer werden und leichter was übersehen werden kann. Am einfachsten ist es, auf kleine Änderungen zu reagieren. Der Versionssprung auf PHP7 war übrigens kein Problem, weil nur sehr alter Code dabei Probleme macht. Der einzige Grund warum es länger ging, ist die Tatsache, dass hier auch Phalcon aktualisiert werden musste, weil Phalcon 2 nicht PHP7-Kompatibel war und meines Wissens nach auch andere PHP-Bibliotheken noch nicht mit der neuen Version kompatibel waren.
-
Der will ja eh nur "dass es funktioniert".
Genau so ist es. Und zwar vollkommen unabhängig davon, ob es sich um OpenSource oder ClosedSource handelt.
Einfach mal ein Beitrag aus einem anderen Forum:
https://www.administrator.de/frage/pf-opnsense-dns-separat-angeben-scheunentor-regel-definiert-wurde-338218.html
Leider kein Einzellfall.
Gruß
Dirk
-
Ich hab nicht den ganze Thread gelesen, aber da gehts dann darum dass input DNS geblockt ist und er hat gemeint mit destination any ist auch ein input erlaubt?
Von Sophos kenne ich das, dass bei Aktivieren von bestimmten Funktionen gleich FW Regeln automatisch gesetzt werden, das wird glaube ich auch teilweise von OPN schon gemacht. Bei HA leider noch nicht, aber da muss man halt einfach nen Issue auf github aufmachen ... und in fremden Foren das zu besprechen ist halt für die Entwickler nicht hilfreich, wer hat schon alle Foren im Blick.
-
Destination any heißt, dass die Zieladresse nicht angeschaut wird. OPNsense hat Standardregeln im Hintergrund - die sind in erster linie dafür da, damit man nicht aus versehen was kaputt macht (zum Beispiel die Erlaubnis von den erforderlichen ICMPv6-Paketen etc.) Für Services gibt es hooks aber die werden erst nach einem Reload aktiv.
-
Ich hab nicht den ganze Thread gelesen...
Der Inhalt ist gar nicht soo wichtig. Wichtiger ist, dass dort von durchaus kompetenten Leuten vom Einsatz der OPNsense abgeraten wird.
Zitat:"Nee, anderes Fazit: Nimm immer pfSense dann ersparst du dir solche Kinkerlitzchen. Die Firmware scheint noch ziemlich buggy zu sein. Andere Filter Optionen funktionieren da auch schlecht bis gar nicht."
Mit Firmware ist in den Fall OPNsense gemeint. ::)
-
> Mit Firmware ist in den Fall OPNsense gemeint. ::)
Was sowohl OPNsense als auf pfSense gemeinsam so in ihren Menüs nennen, also schon korrekt benannt ist :)
Zum Rest mag ich mich gar nicht äußern, das wird nur wieder falsch ausgelegt. Wenn ich die letzten Tage aber von meinen Testsystemen betrachte kann ich das zumindest teilweise bestätigen. Was ich durchaus schade finde.
-
Jetzt mal ganz ehrlich: Warum einen negativen Thread posten um die eigene Meinung zu pushen? Es ist das Internet: man findet über alles was positives wenn man nur lang genug sucht...
Die Luft ist jetzt eindeutig raus aus dem Thread trotz bringha und stefan21, die hier offen diskutieren wollten.
JeGr und monstermania: Wer von euch sieht das auch so, wer nicht? Wer ist bereit sachlich zu diskutieren?
Ich finde langfristig nimmt die Community schaden wenn hier so mit negativer Konnotation argumentiert, geholfen und oder mit den Augen gerollt wird. Und das in einem Thread in dem 1 Problem gefixt wurde und ein anderes erklärt wurde.
-
Es würde mich interessieren, wer bei dem Einsatz einer OPNsense bislang einen Einbruch in ein System vermelden kann, der nicht auf einen unvorsichtigen USER/mangelhafte Konfiguration der Firewall/Dienste zurückzufüren ist.
Die Frage ist kaum bis gar nicht zu beantworten, im Ernstfall ist es aber ein fatales Problem... Updates helfen dabei, aber bringen auch neue Fehler mit sich. Manchmal beheben sie auch kritische unbekannte Fehler älterer Versionen, weil der Code neu geschrieben wird.
Mit HardenedBSD-Extras sind wir nicht von Grund auf unsicherer mit älteren Versionen, weil gewisse Attacken schwieriger werden durch Randomisierung, Stack-Erweiterungen, usw.
Jedoch das Risiko einzugehen nicht zu updaten ist meiner Einschätzung nach Unsinnig solang die Funktionalität nicht beeinträchtigt wird. Ich glaub darum ging es hier im Kern, und dazu führte dann die These, dass man beides haben sollte und dass wir uns da eigentlich einig sind, aber eben die letzten % fehlen.
Wie wir diese letzten % erreichen, ist weiter nicht hinreichend geklärt. :)
Diese Frage stellt sich mir deshalb weil ich gerne ein Gefühl dafür hätte, was zwischen dem letzten Release, und sich aus Zwängen des praktischen Einsatzes ergibt/ergeben hat.
Praktisch ist der UEFI-Support nun stark verbessert und die Treiber sind aktueller. Das fördert die Kompatibilität mit (neuerer) Hardware. Die Rate der Installationsfragen zu Hardware ist seit 17.1.4 merklich gesunken. Und ja, viele brennen USB Sticks vom ISO, aber das geht nicht. Und ja, viele haben USB Sticks die sich mit Windows nicht schreiben lassen, aber das ist nicht zu verhindern wenn die fixe Byte-Sequenz unserer Images nicht 1:1 wiedergegeben wird auf den Stick, aus welchen Gründen auch immer.
Anderst ausgedrückt, hätte mit dem letzten Release tatsächlich ein Einbruch (so denn stattgefunden) vermieden werden können? Und gibt es tatsächlich Kundenanforderungen/Hardwareneuerungen die explizit die Features des letzten Major-Releases, *NACH* der Antwort auf die vorhergehende Frage, einfordern?
Ersteres ist nicht eindeutlich nachweisbar. Statistisch ist die Chance niedriger, dass sich Sicherheitslücken in neuerem Code schneller als Zero-Days exploiten lassen, da man ja Zeit braucht diese zu analysieren/finden. Das mehr an Hardware-Unterstützung ist denke ich erstrebenswert.
Wir reden hier sehr stark über das Betriebssystem, gerade nicht den GUI Code oder die Integration von Third-Party-Software. Dass es hier Defizite gibt ist mir klar, und es ist auch offensichtlich, dass wir keinen echten FreeBSD-Entwickler haben. Ich denke eine Änderung hier wäre wünschenswert. Ob es "die" Lösung ist kann man nicht sagen.
Grüsse
Franco
-
@Franco
Für mich persönlich war der Umstieg auf die 17.1.4ff (32Bit Nano) ein echter Rückschritt in Sachen Stabilität. Ich habe 5 Monate lang die 16.7.x zu Hause genutzt. Lief absolut problemlos und stabil!
Ich habe extra noch etwas mit der Umstellung auf die 17.1 gewartet und habe daher erst im April direkt auf die 17.1.4 umgestellt.
Seit der Umstellung habe ich wiederholt das Symptom, dass plötzlich mein WLAN keine Authentifizierung mehr zulässt. Sprich meine Devices fliegen alle aus dem WLAN. SSID ist weiterhin da, aber es kann keine Verbindung mehr hergestellt werden (Gäste WLAN funktioniert aber weiterhin!).
Ich versuche gerade herauszufinden, ob sich das irgendwie reproduzieren lässt, aber kann bisher noch keine Regelmäßigkeit entdecken.
Gerade gestern abend wieder. Vormittags Update auf die 17.1.7 per VPN-Einwahl durchgeführt (sauber durchgelaufen incl. Reboot). Sitze abends am Tablet -> nach ca. 20-30 Min. plötzlich wieder das WLAN weg! Da ich dann einfach keine Lust habe die Firewall unter dem Schuhschrank herauszukramen um an die LAN-Schnittstelle zu kommen wird eben der Stecker gezogen damit das Teil wieder läuft. 8)
Davor lief das Teil aber einige Tage absolut problemlos sauber durch!
Bin echt schon am überlegen wieder die 16.7'er CF-Karte in die FW einzubauen. Allein schon um sicherzugehen, ob es sich tatsächlich um ein Problem handelt , dass sich auf die 17.1'er eingrenzen lässt.
Klar, ist wieder nur ein Einzelfall. Aber wenn man davon selbst betroffen ist nervt es halt!
Gruß
Dirk
-
> JeGr und monstermania: Wer von euch sieht das auch so, wer nicht? Wer ist bereit sachlich zu diskutieren?
Diskutieren wir unsachlich? War mir zumindest bislang nicht bewusst. Finde ich eher unsachlich, das zu unterstellen.
> Jetzt mal ganz ehrlich: Warum einen negativen Thread posten um die eigene Meinung zu pushen?
Ich zumindest habe nur meine Meinung bzw. eine Idee/Anfrage mit eingebracht. Nämlich ggf. einmal über das Release und Versionsmodell nachzudenken, ob das der aktuellen Entwicklung, Gegebenheiten (wenig Testcases aus der Community über die ihr euch beklagt) und anderen Dingen wie genereller Stabilität etc. genüge tut. Wenn das gleich als Generalangriff gesehen oder gewertet wird, muss ich mich eher wundern. Natürlich ist das Kritik, aber keine bei der (zumindest ich mich nicht) hinstelle und trotzig mit dem Fuß aufstampfend verkünde, dass ich aber ein Eis will. Ich habe lediglich meine Bedenken geäußert. Wenn man/du die ignorieren willst oder als Angriff/Gretchenfrage/whatever abtun willst, dann sei es das. Finde ich aber ebenso bezeichnend, als das Thema gezielt zu Dirk oder mir zurückzuschieben, als würden wir hier Schiffe versenken spielen wollen.
Und wenn man nicht mal mehr im Spaß die Augen rollen darf, sollte man sie vielleicht gleich ganz zu machen... Gleich in die Defensive zu gehen und aus der Opferrolle heraus zu agieren steht euch nicht. Und dem Projekt ebenso nicht. Es gibt aus der von euch so vielgepriesenen offenen Community wie man lesen kann eben durchaus Bedenken und Äußerungen wie meine, die man sich mal einfach durch den Kopf gehen lassen sollte ohne sich gleich salty einzurollen. Und damit lass ichs hier auch gut sein.
BTW wenn dir das mit dem Thread nicht gefällt - was ich als Mod durchaus nachvollziehen kann! - warum nicht einfach den Diskussionsteil hiervon abspalten und mit eigenem Namen weiterführen? Hätte die ganze Zeit schon passieren können. *schulterzuck*
-
@Franco
Für mich persönlich war der Umstieg auf die 17.1.4ff (32Bit Nano) ein echter Rückschritt in Sachen Stabilität. Ich habe 5 Monate lang die 16.7.x zu Hause genutzt. Lief absolut problemlos und stabil!
Ich habe extra noch etwas mit der Umstellung auf die 17.1 gewartet und habe daher erst im April direkt auf die 17.1.4 umgestellt.
Seit der Umstellung habe ich wiederholt das Symptom, dass plötzlich mein WLAN keine Authentifizierung mehr zulässt. Sprich meine Devices fliegen alle aus dem WLAN. SSID ist weiterhin da, aber es kann keine Verbindung mehr hergestellt werden (Gäste WLAN funktioniert aber weiterhin!).
Ich versuche gerade herauszufinden, ob sich das irgendwie reproduzieren lässt, aber kann bisher noch keine Regelmäßigkeit entdecken.
Gerade gestern abend wieder. Vormittags Update auf die 17.1.7 per VPN-Einwahl durchgeführt (sauber durchgelaufen incl. Reboot). Sitze abends am Tablet -> nach ca. 20-30 Min. plötzlich wieder das WLAN weg! Da ich dann einfach keine Lust habe die Firewall unter dem Schuhschrank herauszukramen um an die LAN-Schnittstelle zu kommen wird eben der Stecker gezogen damit das Teil wieder läuft. 8)
Davor lief das Teil aber einige Tage absolut problemlos sauber durch!
Bin echt schon am überlegen wieder die 16.7'er CF-Karte in die FW einzubauen. Allein schon um sicherzugehen, ob es sich tatsächlich um ein Problem handelt , dass sich auf die 17.1'er eingrenzen lässt.
Klar, ist wieder nur ein Einzelfall. Aber wenn man davon selbst betroffen ist nervt es halt!
Gruß
Dirk
Hast du schon nach dem WLAN Adapter/Treiber und Problemen mit der neuen FreeBSD gegoogelt? Wenn da kein Ergebnis kommt mach am besten einen neue Thread auf, da können sich Leute die das gleiche Problem haben anschließen und man kommt eventuell schneller auf eine Lösung.