pfBlockerNG V2.x vs. V3.x (Devel)

Exordium

Moin

Ich habe seit der V3 Installation auf meiner Testfirewall unerklärlich hohe Spikes beim Speicherverbrauch wenn der pfBocker seine Updates verarbeitet. Urplötzlich sind mal die vorher freien 6 GB und zusätzlich noch paar GB Swap weg. Und das, ohne die Mörderauswahl an Blocklisten integriert zu haben. Dazu fliegt dann noch der DNS Resolver ständig aufs Maul.

Ich habe noch eine unserer neuen Appliances aus der Firma zum testen übrig... vielleicht reichen ja die installierten 32GB aus :)

JeGr

@exordium said in pfBlockerNG V2.x vs. V3.x (Devel):

Ich habe seit der V3 Installation auf meiner Testfirewall unerklärlich hohe Spikes beim Speicherverbrauch wenn der pfBocker seine Updates verarbeitet. Urplötzlich sind mal die vorher freien 6 GB und zusätzlich noch paar GB Swap weg. Und das, ohne die Mörderauswahl an Blocklisten integriert zu haben. Dazu fliegt dann noch der DNS Resolver ständig aufs Maul.

Dann hast du wahrscheinlich DNSBL mit drin und/oder noch mit zu viel Zusatzoptionen rumgespielt, die alle im RAM laufen. Ich habe keine Testinstallation, bei der ich mit 4GB nicht problemlos hinkomme und selbst auf der kleinen Kiste mit 2GB renne ich nirgends mit IP-Listen(!) in RAM Probleme. Wenn, dann meistens nur wegen/mit DNS Blocklisten. Und dort hilft Umstellen auf "unbound python mode" extremst um sowohl die ständigen Abbrüche mit DNS Resolver zu verbessern weil kein Neustart notwendig und auch den RAM Verbrauch extrem zu drosseln.

Wir hatten das hier schon in einem anderen Thread. Ich hatte zum Testen ne alte C2758 Box mit 4GB RAM gequält und ALLES an Blocklisten, was aktuell im pfBNG-devel drin ist reingeklopft. ALLES. Sowohl Toulouse als auch Shallalist mit den Porn Kategorien (die ja extrem groß sind), als auch DNSBL Feeds nochmal extra, IP Feeds etc. und selbst da - wie gesagt mit python mode - kein Problem gehabt, Box lief durch. Erst beim Umstellen auf normal, Suppression Listen oder komplettem TLD Blocking etc. dann gabs RAM Tilts.

Ist also alles eine Frage der Config ;)

Exordium

Hmmm, python mode... Gleich nochmal 1 Dutzend böhmische Options mehr zum anclicken.
Übrigens tötet mir irgendwas meine Filterregeln die ich auf Basis der pfBlocker Auswahl "Alias Deny" aufgebaut habe. Gestern 2 neue Regeln eingebaut. Heute sind diese weg und das pfBlocker Dashboard Widget zeigt hinter dem entsprechenden Aliasnamen den "unused" Pfeil...
Gestern direkt nach der Regelaktivierung wurde das noch entsprechend angezeigt.

Also, produktionsreif ist anders.

p54

@exordium deine Aussage "Also, produktionsreif ist anders" würde ich jetzt nicht so stehen lassen wollen. Das Ding funktioniert sehr gut. Ich habe mehrere produktive Firewalls damit im Einsatz.

Und dieser Hinweis:

 Gleich nochmal 1 Dutzend böhmische Options mehr zum anclicken.

hilft auch nicht wirklich. ;) und es macht es auch nicht leichter dir helfen zu wollen, da man schnell den Eindruck erhalten könnte, das du dich damit nicht wirklich auseinander setzten möchtest. >> meine Meinung - spielt aber keine Rolle für dein Problem <<

Aber, vielleicht hilft uns das ja wenn du mehr über deine Umgebung wie den Software-Stand PFSense und Apps mitteilen würdest.

Des weiteren gibt es gute HowTos dazu wie von "Lawrence Systems" auf Youtube oder so gar eine Anleitung mit python: https://www.vikash.nl/setup-pfblockerng-python-mode-with-pfsense/ hier (ich hoffe ich darf fremde Links hier einpflegen).

Zum anderen wie bist du vorgegangen diese Regeln zu hinterlegen? Hast du die Regel auch wirklich aktiv gehabt? Welche Regel war es DNSBL oder IP, wenn IP ist dein WAN Interface damit verknüpft? Unused habe ich so noch nie gesehen muss ich leider zugeben. : )
Und das es am Folgetag > Mutmaßung von mir > die Regel "weg" ist könnte am Update-Intervall liegen, aber dazu bräuchte man mehr infos. Oder stelle es doch nach. Versuche eine neue Regel anzulegen und gehe danach auf PFBlockerNG > Update und führe Select 'Force' option > Update mit Run aus. Ist die Regel danach wenn das Updatefenster mit done quitiert wird noch vorhanden?

Schau doch mal ob du es etwas genauer beschreiben könntest. Das hilft aus der Ferne zumindest einen Eindruck zu gewinnen wo es klemmen könnte.

Wenn dir der freie Support hier im Forum nicht weiterhelfen kann, dann gibt es die Alternativ auch für Unternehmen einen Service Partner ins Boot zu holen, da kann dir aber auch @JeGr sicher sehr gut weiterhelfen einen Dienstleister zu finden der euch Unterstützt wie auch Jahressupport o.ä. (Kostenpflichtig natürlich).

VG

PS: Zum Unused kann es sein das es ein IPv4 Rule ist (IP PFBlocker Blocklist) ? Wenn ja, schau doch mal unter Firewall - Rules nach ob in diesem Interface eine Rule zu sehen ist - je nachdem wie sieh laut, z.B. "pfB_PRI1_v4 auto rule"? Ich glaube dies hatte ich auch schon. Aber ein Reboot hatte bei mir geholfen. Alternativ, Flag weg in General > Keep setting > save und über Package deinstallieren und es erneut versuchen.

Exordium

Also, ich habe seit 2017 pfSenses im Einsatz und bin auch fähig genug eine simple FW-Rule mit nem Alias inside zu erstellen. Die "Autorules" habe ich prinzipiell nicht an, da sie eh immer an der (für mich) falschen Position erscheinen. Bei V2 kein Problem. Bei V3 war die neue Regel am nächsten Tag WEG. Gelöscht... nicht nur verschoben wie bei den Auto-Rules, die mit aller Macht wieder an die alte Position streben... Aber egal... ich suche hier jetzt nicht nach Workarounds für Glitches von "Early Access" Softwarepaketen, sondern berichte nur, was mir beim Einsatz der V3 alles so passiert ist. Das Teil wird gut, keine Frage. Aber auf die Firmenfirewall kommt es mir noch nicht drauf.

Der genannte Dienstleister hat für mich auch schon tätig sein dürfen und wir verstehen uns auch so ganz gut - falls man das hier ohne Konsequenzen rausposaunen darf. Sind zwar nicht immer ganz einer Meinung, aber letztendlich pflegen wir eine gesunde Kommunikation :-)

Ich werde die V3 auf der privaten FW weiterhin testen und mich auch mit dem ominösen python mode herumschlagen zu gegebener Zeit...

p54

@exordium das mit dem glitching verstehe ich in der Tat. Aber @JeGr hat mich dann auch auf den Trichter gebracht, das ich die auto-rule function aus habe :) Dennoch bin ich mit der DEVEL echt zufrieden. Macht eigentlich immer was es soll und das dann doch ganz gut für DEVEL. Die Update-Intervalle haben zwar leider nachgelassen, bedingt durch BBcan177 "Ruhephase" aber es ist so stabil wie es soll. Größere Bugs bis auf die kosmetischen Fehler habe ich aktuell nicht feststellen dürfen.

War mit dem python auch etwas zurückhaltender, aber aktuell würde ich nicht mehr ohne wollen. RAM und Performance sind dadurch schon sehr sehr gut. Geil wäre es halt noch wenn es mit einem AV gekoppelt werden könnte, ähnlich wie squid-guard. Das wäre der Wahnsinn .... sorry ich träume gerade nur ein wenig vor mich hin :) egel, dann happy testing!

VG

Exordium

Ja, ich behalte die Fortschritte mit den Updates und Patches genau im Auge. Steht auch nicht für umme immer noch "Devel" dahinter. Allerdings erhoffte ich mir hier kürzere Entwicklungszyklen. D.h. ein gewisses Kontigent an Features implementieren und dieses ausgiebig bugfixen/testen und diesen Stand wenn er stabiles Status erreicht hat, in die Produktion überführen. Leider finde ich hier aber keine Roadmap/Milestones oder andere Infos wie denn der Zyklus bei dieser Software ist.
Ich hätte erwartet dass man hier auch nach dem Schema

Stable (Aktuelles und stabiles Produktionsrelease)
Testing (Kommendes Produktionsrelease, aber noch Bugs, featurefreezed)
Experimental (Bugs, neue Features, instabil)

vorgeht. Ich möchte ja auch gerne von den neuen Features Gebrauch machen. Aber wie gesagt bin ich hier äußerst vorsichtig was den Einsatz in der Firma angeht.

JeGr

@exordium said in pfBlockerNG V2.x vs. V3.x (Devel):

Gelöscht... nicht nur verschoben wie bei den Auto-Rules, die mit aller Macht wieder an die alte Position streben... Aber egal... ich suche hier jetzt nicht nach Workarounds für Glitches von "Early Access" Softwarepaketen, sondern berichte nur, was mir beim Einsatz der V3 alles so passiert ist. Das Teil wird gut, keine Frage. Aber auf die Firmenfirewall kommt es mir noch nicht drauf.

Definitiv Nein. Das passiert nicht einfach. Da weiß ich nicht was du gemacht oder angelegt hast, aber das passiert einfach nicht. Bei keinem Kunden wo das bei uns rennt. Und die haben alle die -devel da -stable nicht mehr versorgt wird und gerade mit Emotet und Co wieder definitiver Bedarf an Listings da ist.

Wenn du der Meinung bist, das war pfB dann kannst du ja problemlos die Backups durchgehen. Regeländerungen werden im Audit ja hinterlegt. Und da müsste sich dann auch zeigen, was oder wer die Regel angelegt und wieder gelöscht hat. Aber wenn die IP Lists mit Alias Deny/Allow geholt werden und man manuell ne Regel damit anlegt, dann wird die nicht einfach durch pfB verwaltet - außer man benennt sie falsch. Dann kann man aus Gründen durchaus tun, das ist aber auch dokumentiert ;)

Aber egal... ich suche hier jetzt nicht nach Workarounds für Glitches von "Early Access" Softwarepaketen, sondern berichte nur, was mir beim Einsatz der V3 alles so passiert ist.

-devel ist WEIT entfernt von early access und hat damit mal so gar nichts zu tun ;)

Sind zwar nicht immer ganz einer Meinung, aber letztendlich pflegen wir eine gesunde Kommunikation :-)

Dann scheints ja gut zu laufen bei euch ;)

Ich werde die V3 auf der privaten FW weiterhin testen und mich auch mit dem ominösen python mode herumschlagen zu gegebener Zeit...

Da ist nix ominös dran. Ohne python module extension von Unbound: muss neu gestartet werden, verliert Cache, bei VIELEN DNS blocks ist der pre-populate durch die ganzen 0-Blocks der Domains dann recht groß - sprich braucht länger zum Neustart DNS ist für ein paar Sekunden oder so weg was nervt.

Mit Python mode kann über die entsprechende extension der ganze Kram zum einen (so ich mich richtig erinnere) aus Dateien geholt werden was den RAM Verbrauch senkt und zum anderen kann das dann injected werden ohne ständig den Unbound durchzutreten womit der nicht ständig wieder nicht erreichbar ist.

Keine Magie

Steht auch nicht für umme immer noch "Devel" dahinter.

Das ist "Faulheit" von Anthony, ich hatte ihm schon vor 3.1 gesagt, er soll endlich den dann aktuellsten Branch endlich mal abschließen und zum next-stable machen damit mal wieder was Vernünftiges da ist, aber er wollte dann wieder doch erst den Python mode und sonstiges noch einbauen. Nach 3.1 sollte dann aber endlich mal der Fork Update kommen, ich hoffe er arbeitet aktuell dann daran und nicht an noch mehr Features, die aktuell jetzt erstmal "nett" sind aber nicht akut gebraucht werden. Ich möchte da endlich mal nen Branch Update haben. Ansonsten versuch ich ihm demnächst noch ein Testbed für CARP zu bauen.

Leider finde ich hier aber keine Roadmap/Milestones oder andere Infos wie denn der Zyklus bei dieser Software ist.

Das ist EINE Nase, die das ggf. mit Hilfe noch ab und an von Netgate macht. Da gibts keinen Hardcore Release Plan und Development Roadmap und hastenichgesehen :) Das ist ja keine eigene Software, sondern nen Zusatzpaket. Und das hält sich an die Konvention wie andere Pakete auch: stable und devel. Dass er gerade kein Ende findet / finden will um endlich mal umzulabeln, das ist ein anderes Thema - siehe oben - aber da reden wir demnächst nochmal drüber :)

Aber wie gesagt bin ich hier äußerst vorsichtig was den Einsatz in der Firma angeht.

Da bin ich bei DNS vorsichtig, da das oft vital ist. Aber der IP Part läuft IMHO ohne größere Probleme nun schon ewig bei uns und auch bei Kunden. Manchmal gibts "komische" Effekte - hab ja auch 2 Reports gerade offen - aber nichts, was sich hart auf den Betrieb auswirkt.

Cheers

Exordium

Du weisst, ich vertraue Deinen Aussagen. Natürlich besteht immer die Gefahr, dass bei einem Upgrade gemischt mit ersten Konfig-/Gehversuchen gepaart mit einem frischen Schuß "Setupsalat" immer etwas schief gehen kann. Bald ist Urlaub und dann werde ich meine private Sense nochmal einem 2.5.2 /pfb 3.1 clean install unterziehen

Danke für die Anmerkungen und Hilfe!

JeGr

@exordium Ne kein Problem, du weißt auch mein Augenzwinkern zwischen den Zeilen zu lesen

Ich sage auch nicht, dass die 3.1-devel nicht noch an einigen Ecken ziemlich "rough" rüberkommt. Klar. Und dass es bspw. im CARP Betrieb eher suboptimal läuft. Auch da bin ich sofort dabei, weswegen ich schauen möchte, dass wir spätestens ab Januar für Anthony ne Testumgebung haben, auf der er selbst auch rumspielen kann um das besser zu machen.

Sicher ist auch die Integration DNS Blocking, interner Resolver, etc. je nach Einstellung ruppig. Python mode hat da gerade was RAM Verbrauch und Integration angeht viel gebracht. Ich nutze es selbst minimal bis gar nicht, da tatsächlich oftmals DNS meist außerhalb der pfSense schon behandelt wird (bspw. AdGuard oder PiHole Installation schon vorhanden).
Was wir aber vielfach nutzen und am Start haben ist die IP Blocklist Komponente und die läuft eigentlich auch ganz fein. Gerade - und das ist ein guter Punkt - wenn man wie du den default-auto-Regel-Block-Krimskrams abschaltet und statt dessen die Listen auf Alias Deny (oder Permit wenns ne Positivliste ist) schaltet und sich selbst Regeln baut.

Einziger Punkt wo man stolpern kann was mir noch einfiel:

Wenn man Regeln selbst erstellt, gibt es einen Hinweis, der gerne untergeht, weil der wirklich nur als Randnotiz irgendwo in den IP Lists in der Hilfe steht:

When manually creating 'Alias' type firewall rules; Prefix the Firewall rule Description with pfb_ This will ensure that that Dashboard widget reports those statistics correctly. Do not prefix with (pfB_) as those Rules will be auto-removed by package when 'Auto' rules are defined.

Quintessenz: als Beschreibung bitte was mit pfb_ reinschreiben, aber NICHT mit pfB_ sonst werden die ggf. rausgeworfen.
Das könnte ggf. ein Grund sein, warum deine Regeln vllt. aufgeräumt wurden ;)

Allerdings: inzwischen scheint mir der Hinweis eh nicht mehr zu stimmen, denn ich habe bei mir auf der Testkiste 2 Regeln drin ohne Description ohne irgendwas - einfach nur das Alias verwendet - und das wird im Widget inzwischen problemlos erkannt und angezeigt. Daher vllt. "Altlast"

Cheers