[GELÖST] IPSec Bugs

[Helge]

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.

[monstermania]

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

[Helge]

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.

[franco]

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

[monstermania]

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

[franco]

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

[fabian]

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

[franco]

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

[Helge]

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.

[franco]

Dafür gibt es System: Configuration: History.


Grüsse
Franco

[JeGr]

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.

[franco]

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

[fabian]

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

[JeGr]

> 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ß

[franco]

> 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