[GELÖST] IPSec Bugs

[mimugmail]

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 

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. 

[bringha]

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

[JeGr]

@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

[mimugmail]

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

[monstermania]

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
 

[mimugmail]

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

[monstermania]

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

[JeGr]

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

[fabian]

Der will ja eh nur "dass es funktioniert".

Fast: da fehlt noch "und wenig kostet"

[franco]

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

[bringha]

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

[stefan21]

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

[fabian]

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.

[monstermania]

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

[mimugmail]

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.