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.