Firewall Rule mit Alias-Liste trotzdem ein Block im Log zu finden

p54

Hallöchen,

ich habe eine Alias-IP Liste mit einer Menge an Ziel-IPs mit Subnetmasks die ich für div. Ports wie 443 TCP/ UDP usw. für eine Verbindung zulasse, welche auch zum Großteil problemlos zustande kommen.

Dennoch finde ich gelegentlich IPs aus einer dieser Subnetmask Range enthalte IP einen Blocks in den Firewall-Log zu sehen.

Z.B ist ein IP-Bereich in der Alias Liste auf 3.235.96.0 /23 enthalten, dennoch kommt es eben vor das eine IP blockiert wird.

Jun 30 13:34:22 VL_PLAN	10.4.10.4:61350	3.235.96.63:443	TCP:PA

Kann es vielleicht an dem /23 liegen, ich meine damit kommt es öfter vor, müsste ich aber genauer beobachten.

Habt ihr eine Idee dazu? Wäre über jeden Hint erfreut :)

viragomann

@p54
Für das, was da geblockt wird, hat pfSense keine passende Verbindung (out of state). Zu erkennen an dem "PA" Flag.
Eventuell wurde sie bereits geschlossen.
Asymmetrisches Routing kann aber auch eine Ursache für solche Blocks sein.

p54

@viragomann danke für deine Rückmeldung! Ich sehe schon das debugging wird hier etwas aufwendiger als gedacht. Okay, dann werde ich mal versuchen den blockierten Traffic zu capture'n mal sehen ob da noch etwas mehr zu finden ist. Oder gibt es evtl noch einen Anlaufpunkt um es besser zu verstehen wie das vorkommen kann?

viragomann

@p54
Mir fallen aktuell eh nur die beiden genannten möglichen Ursachen ein.

Asymmetrisches Routing würde bedeuten, dass Response-Pakete eine andere Route nehmen als Request-Pakete. Das würde aber generell für die Verbindung gelten, kann aber auch durch Routen-Änderungen (bspw. eine VPN aktiviert) auftreten.
Wenn das also nur ab und zu passiert und sich zu der Zeit keine Routen auf deiner Seite ändern sollten, kann man das ausschließen.

Ansonsten könnte es ein Verbindungs-Timeout sein. Manche Services mögen längere Timeouts.
Die Einstellung von System > Advanced > Firewall & NAT > Firewall Adaptive Timeouts beeinflusst das.
Für spezielle Verbindungen könnten aber unten bei "State Timeouts" oder auch in einzelnen Regeln längere Timeouts gesetzte werden.

Um welche Verbindung geht es hier?

p54

@viragomann ich denke routing via vpn o.ä. kann ich ausschließen.

Ich habe hier ein multi-wan im einsatz. regulär zwinge ich den http /s auf die 2. wan Leitung.
Jedoch die spezielle IP-Alias-Liste mit den Port http /s zwinge ich aus Performancegründen auf die 1. wan Leitung.

Diese Regel in den rules für das Netz mit dieser entsprechenden Alias-Liste liegt vor der Standard-Http /s Rule.
Könnte auch sein, das er versehentlich den ersten request auf der einen wan-Leitung macht und bei der anderen auf die Antwort wartet und somit in den timeout läuft.

Aber dazu muss ich mir erst ein Bild davon machen was das capture sagt auf dem interface. Es ist auch nur sporadisch, aber ich meine das es immer irgendwie diese IP-Range betrifft wenn es im Log zu sehen ist.

Oder aber der Provider für diesen Service pflegt sein Liste nicht richtig - muss ich auch noch klären.
Die Einstellungen für die Timeouts werde ich auch noch checken ob da etwas brauchbares dabei ist. Danke vorab für den Tipp!

VG

viragomann

@p54
Mir würde dazu jetzt nur einfallen, dass das Gateway mit einer aktiven Verbindung als Offline erkannt und damit die Route verworfen wird.
Das sollte aber im Gateway Log ersichtlich sein.

Wenn es mit den Gateways Probleme gibt, kannst du es mit einem Haken bei System > Advanced > Miscellaneous > State Killing on Gateway Failure versuchen.
Das schließt Verbindungen eines Gateways, wenn es Offline geht, was der Client erkennt und so schnell eine neue Verbindung aufbaut.

JeGr

@p54 Das kommt bei 443 tatsächlich ab und an vor und liegt dann ggf. eher an einer trägen Gegenstelle die dann noch Daten schickt, dabei hat die Firewall die Verbindung hier schon zugemacht und den State geschlossen. Ist jetzt gar nicht so sehr unüblich (bei anderen Ports dann schon eher) und bei 443/TLS/SSL kann es auch so mal vorkommen. Ggf. ist da auch ein sehr langer keepalive auf ner Webseite/Anwendung im Spiel der erst viel zu spät kommt.

PA ist ja als Flag "Push Ack" als gabs vorher nen Push bzw. ne Datenverbindung. Ggf. also ein langsamer Server, ein Paket was sich ggf. verirrt hat oder was virago schon sagt out of state/out of bound traffic bei Asymmetrie also das Routing geht verkehrt (über ein IF raus, übers andere rein o.ä.).