pfsense: Erfahrungen mit Werbeblocker pfblockerNG?

[the other]

Moinsen,
seit einiger Zeit nutze ich zum Filtern von Dreck auf DNS Basis den allseits beliebten und bekannten (?) Pihole auf einem Raspi. Das alles funktioniert auch bestens. Trotz goldener Regel "never change a..." stehe ich vor der Frage, ob ich diesen ersetzen sollte durch ein zusätzliches Paket für die pfsense: pfblockerNG.

- Hat jemand dieses Add-on in Benutzung?
- Hat der/diejenige ggf. vorher mal mit Pihole Erfahrungen gesammelt und wenn ja,
- wo liegen aus Eurer Sicht die Unterschiede?
- welches der beiden (oder beide??) nutzt ihr aktuell?
- Was hat eure Entscheidung dahingehend beeinflusst?

Hintergrund der Überlegung: im Rahmen einer Netzwerkerweiterung auf dualstack hadere ich bei dynamischer Präfixvergabe und Unwillen ULAs zu nutzen damit, wie ich den Pihole über Netzsegmentgrenzen hinaus erreichen kann. Daher war eine Idee, auf Pihole zu verzichten und stattdessen pfblockerNG auf der *sense zu nehmen. So könnte ich in den jeweiligen Segmenten easy via local-link Adressen gehen (die Interfaces sind ja im selbigen Netzsegment, daher können die fe80:: Adressen genutzt werden, weil ja kein Routing ansteht).

Oder verrenne ich mich da in eine völlig falsche Richtung?
Zusatzfrage: wie macht ihr das mit IPv6 und dem internen LAN bzw. VLANs was Routing und Adressvergabe anbelangt?

 

[UdoAA]

Ich nutze seit 3 Jahren das pihole auf einem Core i3 7100U mit Ubuntu und bin total zufrieden, funzt super schnell und total unauffällig.
Mehr kann ich dazu nicht beitragen, sorry, aber warum ändern?

 

[the other]

Moinsen,
ändern darum, weil ich mit pfblockerNG einen DNS Blocker auf der *sense hätte. Diese ist über die IP ihrer Interfaces erreichbar. Ich müsste dann für den Raspi mit pihole keine ULA und auch sonst nix einrichten. Die Clients im jeweiligen Netzsegment könnten dann einfach via fe:: local-link Adresse auf den DNS Resolver bzw. vorher eben den DNS Filter zugreifen. Wenn es auf dem Raspi gefiltert wird, dann benötigen die Clients dessen IP. Hier würde in meinem Heimnetz aber kein Zugriff mit fe:: Adressen funzen, da diese nicht über VLAN bzw. Netzsegmentgrenzen hinaus geroutet werden (EDIT: GAR NICHT GEROUTET WERDEN, genauer gesagt). Auf ULA will ich verzichten, also auch keine Lösung. Und feste (also nicht-dynamische Präfixe) gibt es bei meinem ISP nur gegen tüchtig Aufpreis, also sind auch GUAs aktuell nicht verlässlich möglich als Ziel für DNS Anfragen der Clients (wenn ich auch IPv6 Anfragen filtern möchte).

ABER: da ich nur die ersten Schritte im IPv6 Kosmos mache, ist das alles nur der aktuelle Wissensstand (gaaaaanz niedriges Niveau) . Gut möglich also, dass ich in den nächsten Tagen mit etwas Neuem hier auflaufe...oder bis mich jemand von den IPv6 Pros hier zu Recht weist und verbessert...(feel free).

 

[the other]

Moinsen,
wie mich ein gewisser Herr G. aus USA gerade informiert hat, gibt es das Add-on nur für pfsense. Ich passe den Titel also mal besser an...sorry für die Umstände.

 

[blurrrr]

Mussu mal in Dich gehen und Dich fragen, was an der Lösung dann großartig anders ist, als das, was ich Dir sowieso schon vorgeschlagen hatte (Client fragt pfSense) Ob Du den Kram nun "direkt" auf der pfSense laufen lässt, oder über ein zusätzliches Gerät, bleibt natürlich Dir überlassen. Denke, der erste Schritt wäre sowieso, dass die Clients generell erstmal auf die pfSense zugehen. Das kannst Du sowieso machen (oder musst, oder wie auch immer)

 

[the other]

Moinsen,
tja @blurrrr bei mir fallen die Groschen derzeit gefühlt sehr langsam.
Ich habe die letzten Tage noch weiter am IPv6 Projekt geschraubt (aka gelesen).

Zum einen herausgefunden (war für einige hier vermutlich eh klar), dass bei dualstack die DNS Anfragen immer automatisch verlagert werden. Soll heißen: wenn auf IPv6 keine Antwort, dann wird automatisch auf IPv4 gewechselt. Das löst dann meine interne Problematik ziemlich entspannt auf.
Zum anderen werde ich dann die Tage intern umstellen von Pihole auf pfblockerNG. Das hat theoretisch (mal sehen wie es dann praktisch wird) diverse Vorteile für mein setting:
1. Verzicht auf ein zusätzliches Gerät und anfallende Wartung sowie Stromverbrauch
2. DNS Filter und DNS Resolver auf einem Gerät, daher auf allen Interfaces mit der fe:: erreichbar
3. pfsblockerNG kann neben DNSBL auch IPs filtern (Geoblocking etc). Dazu kann es auch mit den üblichen Blocklisten von Pihole umgehen.

Hört sich erstmal nach ner super Lösung an. Wie gewohnt werde ich dann berichten, wie die Einrichtung lief und wie die ersten Erfahrungen so sind...

 

[blurrrr]

Joar, kannste ja auch erstmal alles laufen lassen und erstmal schauen, wie es so läuft... ist ja an sich ein relativ entspanntes Thema

 

[the other]

Moinsen,

ist ja an sich ein relativ entspanntes Thema

Ach ja?

 

[blurrrr]

Na klar, den PiHole kannste ja durchaus erstmal lassen wo er ist. Clients fragen die pfSense, pfSense fragt den PiHole, PiHole fragt da nach, wo er vorher auch schon nachgefragt hat, fertig. Ob die pfSense dann noch selbst macht, oder direkt den PiHole fragt, spielt erstmal keine große Rolle. Wandert ja quasi erstmal nur was "zwischen" die Pipeline... wenn alles läuft, kannste noch am PiHole checken, was der jetzt noch wegwirft, wenn nix mehr weggeworfen wird und alles nach Wunsch funktioniert, schmeisste den PiHole raus und jut ist. Somit läuft der Betrieb relativ unterbrechnungsfrei und der "Schutz" ist nach wie vor gewährleistet.

 

[the other]

Moinsen,
...sooo. Das Paket läuft.
Nach Verteilung des "neuen" DNS Servers via dhcp und vorherigem Einpflegen der IP-Listen und DNSBL wird in den ersten Versuchen alles weggeblockt. Aufruf der Seiten ist unverändert schnell zu Pihole. Testversuche zu geblockten Seiten zeigt schön ein Fenster an, dass der Zugriff auf die Seite wegen pfblockerNG gesperrt wurde. Auch schön als Rückmeldung.
Aktuell fragen jetzt also alle bei DNS Fragen den unbound Server, auf welchem pfblockerNGdev integriert ist. Super.
Mal schauen, ob es so stabil weiter läuft.

Auch bisher klare + Punkte:
- die Listen (ob IP oder DNSBL) werden automatisch aktualisiert (einmal täglich, kann aber angepasst werden)
- RAM Nutzung bei ca. 35% auf dem APU Board
- viele Listen als Vorauswahl vorhanden, können einzeln gewählt werden

Ick freu mir....