pfBlockerNG sperry eine IP der Shellycloud

[Fidibus]

Moin,
nach dem Update der pfsenseCE auf 2.9.0 fällt mir im Log ein deny meine shellys auf:

Sep 23 07:13:40

LAN

pfB_PRI1_v4 auto rule (1770006073)

192.168.18.16:6259

23.251.142.183:6011

TCP:S

Ob das unmittelbar mit dem Update zusammenhängt, ich glaube es ehr nicht, aber zumindest ist es mir vorher nicht aufgefallen.
Ich habe gestern mit der KI einige Ansätze versucht, das Problem zu lösen, da ich annehme, dass diese Verbindung schon seine Sinn hat, wenn die Shellycloude genutzt werden soll.
Nach einer gewissen Zeit der Erfolglosigkeit, hat sich die KI im Kreis gedreht.
Es ist mir bisher nicht gelungen, eine Ausnahme in pfBlocker einzupflegen, den Portrange (6022, 6011, 6021, 6012, 6013, 6015, 6020, 80) dafür zu definieren, der dann auch dauerhaft ein Reload vom pfBlocker sinnvoll übersteht.
Hat einer von euch einen Ansatz?

 

[blurrrr]

Moin,

PTR ist halt ...googleusercontent.com, vielleicht wird das ja schon geblockt Kannst Du nicht etwas in Richtung Whitelist (Alias) konfigurieren (mit FQDNs) und die Einträge entsprechend erlauben (vermutlich dann als permit outbound)? Da ich pfblockerng nicht nutze... vielleicht ist der Part hier auch noch interessant diesbezüglich:

pfBlocker always moves its rules to the top, how can I stop this?:
Change rule action to Alias only and then apply custom rules using pfBlockeraliases with an arbitrary sequence.

Quelle: https://docs.netgate.com/pfsense/en/latest/packages/pfblocker.html#faq

Aber vielleicht hast Du das ja sowieso schon so konfiguriert

 

[Fidibus]

Danke dir, ja, da war ich schon durch. Ich konnte beim pfBlocker letztendlich kein Ziel definieren...nur any, die bewußte IP hat er als Quelle eingebaut :-/
Egal wie...white-list, Regel...

 

[blurrrr]

Weiss ja nicht, wie Du es bisher so konfiguriert hast, aber ich nehme doch mal an, dass Du eine (oder mehrere) Listen erstellt hast. Irgendwelche Automatismen würde ich da persönlich wohl eher raus lassen und die Listen - wie auch schon im Zitat erwähnt - einfach nur als Alias definieren und dann die Regeln manuell setzen (halt je nachdem ein-/ausgehend). Dabei kannst Du halt noch explizit eine Allow-Regel erstellen (für die Shelly-Sachen), welche eben "vor" der "deny"-Regel der div. Listen/Aliase steht. Somit sollte diese Regel auch vor den anderen Regeln greifen und Dein Problem sollte erledigt sein.

pfB_PRI1_v4 auto rule (1770006073)

Besagt ja schon, dass es eine "automatisch" erstellte Regel ist.

 

[Fidibus]

Ich mache da wohl was Entscheidendes falsch:

Reaktion im Log:

 

[the other]

Moinsen,
geht es denn, wenn du die auto-Rule mal (kurz) deaktivierst?

 

[Fidibus]

mal (kurz) deaktivierst

Mich verwirrt da gerade das nun geloggte Absender-IF....
Das Logging ist auf der allowed Rule am LAN-IF.

 

[the other]

Moinsen,
ein paar Fragen dazu:
warum hast du eine Floating rule für das LAN Interface (IF), wenn du dort ebenfalls eine gleiche Regel hast (oder interpretiere ich das falsch)?
Warum (wie ja @blurrrr schon meinte) nutzt du die auto-rules? Alternative (und vielfach als besser befunden) wäre es, eine eigene Alias Regel dafür anzulegen, die kannst du dann einfacher da anbringen, wo sie wirken soll (zB direkt am Interface, an dem sich die shellys befinden).

Ich nutze hier zB gar keine Floating rules. Finde die immer so als Schattenregelwerk...da ich aber auch nur 11 produktiv genutzte Subnetze hier habe (also auch 11 IFs) ist der Aufwand vertretbar, die Regeln direkt als Interfaceregeln zu erstellen.
Mit pfblocker nutze ich explizit eben KEINE autorules (eben weil die im Hintergrund werkeln), sondern nutze besagte Alias Regel:

Dann beim gewünschten Interface eine neue Regel anlegen, hier bei Destination "Alias" auswählen und die Regel einfügen...
Und schließlich darüber (!) dann die Ausnahme für die shelly cloud IP...das sollte dann eigentlich funzen.

 

[Fidibus]

@the other :
Die Floating Rules sind bei der Nutzung des pfBlockers alleine "mit entstanden".
(Weiter, weiter, Fertigstellen )
Die Regeln werden bei jedem Update sozusagen "neu" erzeugt - zumindest hab ich das so verstanden und erlebt.
Ggf. bin ich ja auch falsch beim Auswählen der Interface für den pfBlocker - muss ich noch mal abtauchen.
Die Regel für die Shellys liegt direkt auf dem entsprechenden IF, hier LAN.
Ich habe dann, wie beschrieben, bei der Kontrolle nach dem Update, festgestellt, dass die Shellys auf eine IP halt neu wollten. Beim Erweitern der Bestandsregel blieb der deny halt bestehen.
Irgendwo im pfBlocker ist in einem Range wohl die IP mit drin - ich hab noch nicht gefunden, wo.
Wäre auch egal, beim nächsten auto-Update wäre der Bereich eh wieder komplett.
Ich schaue mir den Weg, den du vorschlägst mal an.