pfSense 2.6.0 oder pfSense+

JeGr

@nonick Das eine braucht aktuell das andere, also müssen wir eh erstmal alle 2.6 installieren bevor sich die Frage stellt, da es kein Plus Image zur Neuinstallation gibt :)

@nonick said in pfSense 2.6.0 oder pfSense+:

Wenn man zur Plus wechselt benötigt man einen Token. Wie verhält sich das wenn man zwei Geräte hat (Produktiv, Backup).

Einfache Antwort die auch schon mehrfach beantwortet wurde und im Blog/Doku etc. steht. Die Tokens werden an Hand der Netgate ID erstellt. Zweite Box, zweites Token. Ganz einfach :)

Die Netgate ID wird FYI vom binary /usr/sbin/gnid generiert und ist ein SHA256 gekürzter Hash über der Architektur und den MAC Adressen der NICs. Da die beim Gerät eigentlich meistens gleich bleiben während Dinge wie RAM etc. gern wechseln, sollte das in den wenigstens Fällen problematisch sein.

Wenn man in Zukunft eine saubere Neuinstallation von der Plus Version machen möchte, wo bekommt man dann die Software her? Es kann ja nicht sein das man immer erst die CE Version installieren muss um dann zu Upgraden. Eine saubere Neuinstallation wäre das auch nicht.

Siehe oben oder Doku: https://docs.netgate.com/pfsense/en/latest/install/migrate-to-plus.html#requirements

Der aktuelle Prozess ist und bleibt (erst einmal): Installation von 2.6, wenn NDI bekannt (vorher schon Token erstellt worden) wird 22.01 Upgrade angeboten. Done. Wie das mit zukünftigen Releases aussieht oder ob/wenn später ggf. ein Plus Image zur Installation bereit steht - wird man sehen. Das Problem wird eher sein, dass man sinnvollerweise den User nicht erst Plus installieren lassen kann um ihm hinterher zu sagen "nee bäh du darfst kein Plus". Da hat keiner gewonnen. Also ist die CE installieren und Upgraden einfacher/sicherer, dann hat derjenige auf jeden Fall was, was funktioniert egal ob sein Token erkannt wird oder nicht.

Cheers

nonick

@jegr Auf Jens ist eben Verlass
Danke, das hat mir sehr geholfen. Jetzt würde mich nur noch interessieren welche Version du nutzt, 2.6.0 oder pfSense+? Sag jetzt ja nicht 2.5.2 dann welche es in Zukunft sein wird.

Bob.Dig

@nonick Wobei die Frage interessant bleibt. Ich habe letztens eine Config einer PfSense, die ich schon mal auf Plus geupgradet hatte, auf eine freshe Installation einer CE übertragen. Allerdings war die Config inzwischen eh von einer CE gewesen, da ich davor wegen Problemen ein Image zurückspielen musste. Bei erneuter Eingabe des selben Token wie einst wurde dieser nicht mehr akzeptiert.
Also es scheint keine Verbindung zu bestehen, zwischen ID und Upgrade oder die ID ist nicht Teil der Config.

Hat schon jemand versucht eine aktuelle Plus-Config auf eine CE zu übertragen?
Sry, wenn es etwas kompliziert zu lesen ist...

Im Idealfall wäre die ID und der Upgradestatus Teil des config-backups und es gäbe dafür unaktivierte plus-Images.

BTW was sehr positiv zu bewerten ist, ist dass die beiden Versionen jetzt wieder eine einheitliche Basis haben. Das war ja schon mal anders und hat Befürchtungen verstärkt, dass die CE bald Geschichte sein könnte. Ob hier ein Umdenken bei Netgate stattgefunden hat?

JeGr

@nonick said in pfSense 2.6.0 oder pfSense+:

@jegr Auf Jens ist eben Verlass
Danke, das hat mir sehr geholfen. Jetzt würde mich nur noch interessieren welche Version du nutzt, 2.6.0 oder pfSense+? Sag jetzt ja nicht 2.5.2 dann welche es in Zukunft sein wird.

Aktuell 2.5.2

Das hat aber eher damit zu tun, dass ich gerade von Kunde zu Kunde renne um ein System nach dem nächsten zu betreuen, upzudaten oder komplett zu retten. Gerade ist extrem viel los, da will man dann nicht nach Feierabend noch stundenlang selbst am eigenen Rack stehen

Tatsächlich wirds in meinem Fall für mich aber beide Versionen sein, da ich einfach beide im Auge behalten muss, schon alleine wie sie sich entwickeln. Daher werde ich mir für meine Boxen definitiv ein zwei Tokens ranholen, schon allein um eine TestVM oder Hardware zu haben. Eine Plus-HW habe ich zum testen eh (2100) aber ansonsten gibt es gerade für mich vergleichsweise wenig Grund schon auf die Plus zu wechseln. Da Privat/Lab eh später auch freie Tokens bekommen gibts da auch wenig Druck.

Als (kleine) Firma sähe das anders aus. Da die geplanten weiteren Updates und Entwicklungen ja auf Firmenkunden abzielen und man jetzt für eine Übergangszeit ein freies Token pro Gerät kostenlos bekommt, wäre es ggf. schlau zu wechseln, wenn man zukünftig auf die angekündigten Features wert legt. Für kleinere Firmen mit einer Box oder nem kleinen Cluster - hm. Das muss sich zeigen. Die schnelleren Updates sind für manche Kundentypen eher abschreckend, die jetzt noch auf 2.4.5-p1 hängen und grade 2.5.2 vorbereiten, die kommen mit 2.6 schon nicht hinterher. Wenn da dann alle 4 Monate ein Update reinrauscht sind die nach nem Jahr 1-2 Releases hinterher, weil sie gar nicht nachkommen mit Updaten.

Daher: schwierig, ich kann da keine Empfehlung aussprechen, weil keiner wirklich in die Zukunft schauen kann, was da jetzt noch kommen wird und wie schnell sich die Versionen dann tatsächlich entwickeln. Daher ist aktuell ja bspw. auch das Update 2.6->22.01 simpel - da die Versionen sich kaum unterscheiden.

@bob-dig said in pfSense 2.6.0 oder pfSense+:

Hat schon jemand versucht eine aktuelle Plus-Config auf eine CE zu übertragen?

Sollte wie oben schon angemerkt aktuell kaum ein Problem sein, da zum größten Teil identisch. Lediglich die paar Pakete der Plus sind da im Spiel, ansonsten ist der Funktionsumfang identisch ergo auch gleicher XML Inhalt.
Schwierig wirds eher, wenn man von ARM Hardware kommt die ggf. noch Switch enthält, denn das ist sehr Plus/Netgate spezifisch.

@bob-dig said in pfSense 2.6.0 oder pfSense+:

Im Idealfall wäre die ID und der Upgradestatus Teil des config-backups und es gäbe dafür unaktivierte plus-Images.

Nein die ID wird über die Hardware generiert und sollte identisch/gleich bleiben. Da diese über Architektur + MACs der Interfaces erstellt wird, bleibt die auch im Normalfall gleich. Keine Ahnung was du gebastelt hast, dass die abweicht, aber das klingt nach VM und neuen MACs für die NICs. Dann ändert sich natürlich auch die ID, das wundert dann nicht. Die ID wird von einem Binary erzeugt und ausgespuckt, das eigentlich immer den gleichen Wert erzeugt (SHA256 über Arch+MACs zusammengewürfelt).

@bob-dig said in pfSense 2.6.0 oder pfSense+:

es gäbe dafür unaktivierte plus-Images.

siehe gestern das Thema. Halte ich nicht für sinnvoll aktuell, da man dann ganz schnell in die Falle laufen kann, dass jemand wie du rumbastelt, die ID sich ändert und du ein Plus Image installierst, dass du nach Installation nicht verwenden kannst weil die ID nicht erkannt wird. Wie soll sich die Software dann verhalten? Betrieb einstellen? Das wäre der Mega-GAU und ein PR Desaster, dann würde wieder jeder schreien "HA! Wir habens ja gesagt, jetzt haben sie da Lizenzen drin und schon geht gar nix mehr!". Genau deshalb ist der Schritt aktuell gar nicht un-smart, denn so hast du auf jeden Fall ne funktionale 2.6 Version wenn das Upgrade nicht erkannt wird und kannst DANN dich drum kümmern, warum das Token nicht erkannt wird. (oder dir ein neues holen)

@bob-dig said in pfSense 2.6.0 oder pfSense+:

BTW was sehr positiv zu bewerten ist, ist dass die beiden Versionen jetzt wieder eine einheitliche Basis haben. Das war ja schon mal anders und hat Befürchtungen verstärkt, dass die CE bald Geschichte sein könnte. Ob hier ein Umdenken bei Netgate stattgefunden hat?

Tatsächlich glaube ich das nicht, auch wenn es schön und positiv wäre. Aber IMHO ist es lediglich so, dass viele es komplett nicht verstanden haben, wie der Dev-Weg von Plus und CE jetzt aussehen könnte und dann das Geschrei groß war. Dass zudem 2.6 ein joint-release mit einer Plus wird, war von vornherein klar als 2.5 und Plus letztes Jahr angekündigt wurden. Stand sogar groß im Blog. Wie es jetzt weitergeht wird eher die interessante Beobachtung sein.

Cheers

Bob.Dig

@jegr Gut zu wissen, das mit den MACs, darauf muss ich das nächste mal achten.
Worauf ich auch zukünftig achten will, dass die erste NIC besser LAN sein sollte... Notiz an mich selbst.

Was die Zukunft der CE betrifft, da bist Du ja gefühlt jetzt pessimistischer unterwegs als früher? Kenn ich ja von Dir nicht.

JeGr

@bob-dig said in pfSense 2.6.0 oder pfSense+:

dass die erste NIC besser LAN sein sollte... Notiz an mich selbst.

Warum die erste? Die erste ist normalerweise im System immer WAN, die zweite die zugewiesen wird ist LAN?

Was die Zukunft der CE betrifft, da bist Du ja gefühlt jetzt pessimistischer unterwegs als früher? Kenn ich ja von Dir nicht.

Wo liest du da Pessimismus? Ich bin nur nach zigfachen Stunden unsinnigen und unnötigen Gesabbels es einfach leid immer wieder runterzubeten. So viel Lebenszeit ist es mir einfach nicht wert immer und immer wieder aufzuzeigen, warum das meiste geschriebene Zeugs einfach nur aktuell haltlose Behauptungen, Vermutungen und Mutmaßungen sind, die auf nichts außer auf Bauchgefühl und sonstigen kosmischen Schwingungen beruht. Alles andere KANN sich erst jetzt überhaupt zeigen! Denn jetzt gibt es erst den Weg, die Leute mittels Token zu Plus zu "konvertieren" und erst jetzt ist überhaupt ein Pricing klar, was der Kram kosten soll.
Tatsächlich ist der Preis aber nicht anders, als der von bspw. OPNsense und seiner Business Edition. Also gar nicht mal so dramatisch wie man das aufgeblasen hat. Und dann können Firmen, die auf das Pferd setzen wollen jetzt sogar noch gratis wechseln. Wie es dann mit Plus & CE weitergeht kann man überhaupt erst jetzt an den zukünftigen Releases sehen. Was will man vorher gewusst oder gesehen haben? Nichts. Alles nur Vermutungen und heiße Luft. "Aber die 21.05... aber die 21.09... aber an den Plus Versionen sieht man ja dass die anderen Code... " Nein. Es gab nur andere Release Zyklen und nicht alles wurde eben gleich in die CE gestopft. Genauso wie es angekündigt war, dass die Plus die rapid devel Version werden würde. Genau das haben sie bislang gemacht.

Daher ist mir das grade völlig egal, da es beim aktuellen Stand eben außer ein paar Plugins keinen Grund gibt, spezifisch den einen oder anderen Branch zu nutzen und für uns Privatkunden ist es schon 2x egal weil wir eh immer kostenlos nen Update auf Plus bekommen würden. Ich sage also nichts anderes wie gebetsmühlenartig seit mehr als einem Jahr: dass man abwarten muss wie sich das entwickelt sobald es mal Änderungen gibt, die wirklich eigenständig zu Plus gehören!

Darum: blub

Cheers

Bob.Dig

@jegr said in pfSense 2.6.0 oder pfSense+:

@bob-dig said in pfSense 2.6.0 oder pfSense+:

dass die erste NIC besser LAN sein sollte... Notiz an mich selbst.

Warum die erste? Die erste ist normalerweise im System immer WAN, die zweite die zugewiesen wird ist LAN?

Ich musste LAN von hn1 auf hn0 bringen, was mir nur mit edit der config möglich war.

nonick

Was ich nicht verstehe, wenn Privatkunden immer kostenlos das Update auf pfSense+ bekommen und Firmen wegen dem Support sowieso auf diese wechseln, für wem ist dann in Zukunft die CE Version?

Na gut, nachdem ich mir die Lizenzbedingungen von pfSense+ durchgelesen habe, ist mir einiges klarer geworden.

JeGr

@nonick said in pfSense 2.6.0 oder pfSense+:

Na gut, nachdem ich mir die Lizenzbedingungen von pfSense+ durchgelesen habe, ist mir einiges klarer geworden.

Hinsichtlich was? Die Lizenzbedingungen haben sich nicht essentiell verändert.

@nonick said in pfSense 2.6.0 oder pfSense+:

und Firmen wegen dem Support sowieso auf diese wechseln

Nicht alle Firmen wechseln weil sie es nicht brauchen. Die wenigsten brauchen wirklich TAC lite und es gibt (leider) häufig Kunden, die gern nur "kostenlos" wollen. Und im KMU Bereich braucht es häufig keine großen Features.

nonick

@jegr Zwei Sachen gefallen mir an den "Evaluation Agreement" nicht, vielleicht ist es auch missverständlich ausgedrückt.

Software provided by Netgate may contain tracking and/or disabling features
Evaluator agrees to provide Netgate personnel full and free access to the Product, including remote access, subject to the Evaluator’s security regulations, for the purpose of observing the testing and performance of the Product.

viragomann

@nonick
Diese Sache stößt mir auch sauer auf.

Dazu gab es vor 2 Wochen bereits einen Post in General, den ich beobachte, der aber bis heute nicht beantwortet wurde:
https://forum.netgate.com/topic/170080/remote-access-and-tracking-in-pfsense

slu

@viragomann said in pfSense 2.6.0 oder pfSense+:

Diese Sache stößt mir auch sauer auf.

Mir auch.

JeGr

Hmm, ich mutmaße - weil ichs nicht weiß - dass sich das u.a. auf die Netgate ID (NID) und daraufhin auf das Token bezieht und da wieder viel "Legaleese" drinsteckt wegen weil Absicherung und Co. aber ich habs auch mal weiter oben angestoßen und getriggert ob man da nicht ne Antwort geben kann.

JeGr

Ah ich war nur blind. Die Antwort steht direkt bei Reddit unter dem zitierten Beitrag, da war nur jemand zu faul zu suchen oder zu verlinken.

Statement von kphilips:

You know....you try to get a solid 8 hours of sleep and this is what you wake up to.....sips my cup of tea.....OK here we go:

There is no super secret backdoor into your firewall and we certainly aren't going to just remote into your firewall (even if we could) without your permission, whether on pfSense CE or pfSense Plus. Anyone who has ever opened a TAC ticket that required us to remote in to take a look knows that we explicitly ask for access via a firewall rule from a specific source subnet on our network or we do a screensharing session, whichever the end user is most comfortable with. And if they're not comfortable with either, we do our best to accommodate.

The point I was trying to make with the iTunes joke is that legal verbage is a funny thing. Kind of like those funny laws you hear about in a random town in Minnesota where you're not allowed to have a shark in a bathtub on your lawn after midnight or whatever. As an outsider looking in, I'd imagine being a person in legal is a lot of CYA, so what I was TRYING to say is don't mistake a random line in a EULA as maliciousness.

I'm not a lawyer and nobody else that mods this subreddit from Netgate is either, to my knowledge. We're all volunteers who take time out of our day to provide answers to things like tech support questions. In fact, I'm responding to this right now outside of normal working hours for me. The reason I locked the other threads is because anyone here commenting on it, beyond what I've said, would be futile. Reddit isn't an appropriate place for these kinds of questions. If you're a Netgate customer who has questions about our products and the licensing for them, as I said, reach out to Netgate directly and ask. Our phone number and emails are right on our web site.

I get it. Reddit, and the internet at large, LOVES drama and burns it like a red hot coal engine running down the tracks at 500 mph, but Netgate isn't big brother and we're not putting backdoor software into your firewall.

I hope the above is enough to satisfy concerns. If it's not, I'm sorry and I encourage you to reach out via an appropriate channel. Like I said in my previous response I'm locking this thread as well (just like I said I would). Please refrain from trying to continue opening threads like this for the reasons above.

I sincerely hope you all are having a wonderful weekend and a great day. Take care.

Blumige Sprache beiseite gelassen, kurz zu den Punkten:

...remote into system...: Ja da hat er recht und das deckt sich mit unserer Erfahrung mit dem Netgate Team und den Supportern. Wenn die wirklich mal access anfordern (und das tun sie im Ticket gezielt nachdem sie Infos vorher anfordern etc., da wird nicht einfach gesagt ja wir machen alles selbst) dann gezielt von ihrem Support Subnetz und mit einem Extra User für sie damit es nachvollziehbar bleibt. Oder es gibt nen Screenshare mit dem Supporter.
reach out to Netgate: Auch nicht falsch, wenn man eine EULA nicht abnicken will oder fragen dazu hat, dann meldet man sich eben bei der Firma. JA, natürlich kann man jetzt anführen, dass sie es doch einfach alles selbst hier posten sollen, aber ganz ehrlich, es wird gerade im Zuge der Plus Migration wieder so viel FUD und Kram betrieben, dass das mehrere Vollzeit Jobs wären, jeden Tag hier im Forum+Reddit+Twitter+whatever jede Sorge und jedes Gerücht zu entkräften. Und dann hat man noch die Aluhüte, die dann die Entkräftung nehmen um zu sagen "ja das wird jetzt aber extra hart dementiert, da MUSS dann ja was dran sein!!11elf". Ist halt wie die Covid-Diskussion, wenn jemand "seine Meinung" hat, wirst die Diskussion unsinnig, die Person findet dann immer irgendwas um sich ihren Standpunkt zu bekräftigen.

Auf einen Punkt muss ich aber hinweisen:

@nonick said in pfSense 2.6.0 oder pfSense+:

Evaluator agrees to provide Netgate personnel full and free access to the Product, including remote access, subject to the Evaluator’s security regulations, for the purpose of observing the testing and performance of the Product.

Da wird bspw. explizit genannt "Zugriff auf das Produkt - gemäß Vorgabe/Maßgabe/Security Policy des Testers! - zum Zwecke der Begutachtung des Tests und der Performance des Produkts.
Gemäß den Vorgaben des Testenden ist hier im Regelfall der Knackpunkt. Wenn meine Vorgabe ist, mein Labor/Testumgebung ist heilig und da schaut keiner rein, dann schaut da keiner rein. Blöd gesagt.

Der Punkt ist, es geht in dem zweiten Punkt explizit um einen "Testenden". Evaluator. Meiner Ansicht nach sichert man sich da ab, dass man ggf. mal anonyme Metriken anfrägt o.ä. wenn man von ner (großen) Firma "diverse" Testlizenzen angefragt bekommt. Ständig. Viele. Wenn mir bspw. FORD o.ä. ständig Anfragen reinschickt "need pfSense Plus testing/eval license for our new lab in Canada...", "our new lab in Germany...", "our new lab in Tokyo...", dann würde ich da auch reingrätschen und sagen Moooooment mal! 30 Labore mit CARP (x2 Lizenzen) rund um die Welt die "alle testen müssen"?

Ich glaube nicht Tim!

Und wie gesagt der erste Punkt mit dem Tracking/Disable Feature ist meiner Mutmaßung nach zweigeteilt.

wird es um die NID und die Token Generierung gehen, was ja u.a. dann bei Paketupdates als User Agent mitgeschickt wird, damit man unterscheiden kann ob die Kiste das Plus Repo verwenden darf oder nicht. Das ist ja völlig legitim, kann aber eben getrackt werden wie ein User/Pass in der Repo URL auch geloggt werden kann. Daher muss das auch ins Legal Agreement dass man das weiß
denke ich, dass es auch um zukünftige Absicherung geht, da man ja bereits (indirekt) angekündigt hat, dass es später auch Dienste geben könnte, die man noch "on top" auf die Plus zusätzlich anbietet/verkauft und diese müssen ja auch über eine Möglichkeit verfügen geprüft zu werden, ob man "noch Kunde von Plus+SuperDuperBlocklist" oder nur noch "Plus" Kunde ist. Also muss es "enable/disable" von Funktionen geben.

Daher bin ich auch hier eher pragmatisch und sage "wird wieder viel Lärm gemacht um wenig Background".

Ich kann das Fass gern mal versuchen über den Partner Channel/Mail aufzumachen, aber ich denke wie ausgeführt eher, dass es hier um "Legaleese" (Rechtsverdreher-Arsch-an-die-Wand-Formulierungskram) geht als um hands down Drama Facts.

Cheers und take care!
\jens