Firewall / Routing funktionieren nicht wie erwartet.

Started by Radon, October 28, 2024, 08:30:36 PM

Previous topic - Next topic
Quote from: Radon on November 06, 2024, 08:19:19 PM
Die Pakete die vorher in dieser "Default deny / state violation rule" geloggt wurden, werden nun einfach in meiner neuen Regel geloggt.
Hätte ich nicht erwartet. So gut kenne ich OPNsense dann wohl auch noch nicht.

Man könnte sich mit den TCP Flags in der manuellen Block Regel spielen, um das wegzubekommen. Aber das Problem hatte ich bislang nicht.

Besser wäre es, das Problem, das ja ein solche gewiss ist, zu beseitigen.

QuoteUnd ich weiss wirklich nicht wie ich die "falsch geblockten" weg kriege. Zudem bin ich immernoch leicht verwirrt wieso diese überhaupt geblockt werden, soll die Applikation doch einfach erneut "freigegeben" werden. Offenbar wollen das viele Applikationen so, denn es taucht bei sehr vielen Geräten fast identisch immer wieder auf und die Regel würde ja passen und trotzdem wird sie geblockt.
Im Live Log solle sich ganz rechts ein Info-Symbol befinden. Klick da bei ein paar Blocks mal drauf und sieh die an, welches TCP Flag das Paket hatte.
Das mit dem Timeouts war mal eine Vermutung und passt zu den Pass-Logs davor, es könnte aber auch ein asymmetrisches Routing gewisser Pakete dafür verantwortlich sein.

Falls es Timeouts sind und deine Geräte damit Probleme haben, könntest du den State timeout in der Pass-Regel in den Advanced features erhöhen. 30 Minuten ist Standard, soweit ich weiß.
Oder ganz brutal, du kannst und eigentlich nicht empfohlen, du kannst den State Type auf None stellen. Dann ist OPNsense egal, ob es keinen State mehr gibt und lässt das Paket durch. Ob am anderen Ende noch jemand darauf wartet, ist eine andere Frage.

QuoteOder nochmals einen anderen Gedanken: könnte es ein Problem mit dem Interface/Treiber sein?
Ein Treiber Problem kann ich auch nicht ausschließen, aber um das zu beurteilen,gibt es andere Spezialisten hier.

Ah, das mit den TCP Flags war ein super Tipp!! Danke!!

Ich habe dann diese Beiträge gefunden, die das Thema sehr gut im Detail erklären:
https://forum.opnsense.org/index.php?topic=4758.0
https://forum.opnsense.org/index.php?topic=20219.0
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html

Kurz: Alle "normalen" TCP Regeln matchen nur falls ein Packet mit dem TCP Flag SYN (oder "tcpflags: S" im Log) kommen um einen neuen state zu erstellen. Alle anderen TCP Flags werden geblockt, falls keine Verbindung in den States bereits offen ist.

Damit habe ich nun auch etwas genauer hingeschaut und tatsächlich alle meine "ungewollten" Log Einträge haben ein TCP Flag ACK drin. Heisst das erklärt definitiv 100% von meinem "Problem 1". So gut kannte ich das TCP Protokoll gar nicht zuvor  ::)

Ich probiere noch etwas rum. Aber so wie es bisher scheint, funktioniert eine Block Regel mit TCP Flag ACK und ich diese nicht mehr logge. Die erste Stunde scheint es perferkt zu funktionieren und ich habe diese ungewollten Logeinträge nicht mehr.
Default Deny ist wieder drin und loggt mir "alles andere" was ich sehen will.


Mein Problem 2 muss ich auch nochals genauer anschauen. Denn nach ein paar Tagen bockt das Smartphone jetzt auch mit der anderen IP rum und kommt nicht immer auf HomeAssistant. Kann nicht sein, dass ich alle paar Tage die IP Zuweisung im DHCP Server ändern muss, damit es funktioniert  :-\

Hallo zusammen

So ich konnte alle meine aktuell bekannten Probleme lösen  :D
Danke nochmals vielmals ür die Anregungen. Vor allem an dich viragomann

Für diejenigen die an der Lösung interessiert sind:
Beide meiner Probleme hatten mit diesen TCP Flags zu tun.
Wieso die "unerwarteten" Log Einträge auftauchen ist oben bereits beschrieben, bzw. in den Links im Detail.

Für diejenigen die diese Einträge aber ebenfalls nicht im Log haben möchten, mit einer Firewall Regel die folgendes beinhaltet, werden diese Pakete nicht mehr im Log eingetragen:
Eine block Regel mit "All to All" und in den Advanced features TCP flags "out of SYN" auswählen. Siehe auch Bilder.
Wenn es euch nur in der Darstellung stört, könnt ihr auch einen Filter Setzen in der Live View mit "tcpflags does not contain ACK"

So nun noch zu meinem zweiten Problem:
Wieso das genau so ist, bin ich bis jetzt nicht sicher, aber ich vermute das hat mit der HomeAssistant App zu tun die nicht bemerkt hat, dass die Verbindung geschlossen wurde.
Jedenfalls habe ich meine bestehende Firewall Regel "Ziel HomeAssistant TCP Port 8123" angepasst und in den Advanced features habe ich zusätzlich TCP flags "Any flags" ausgewählt. Siehe auch hier die Bilder.
Seither kommen alle Smartphones reibungslos über die App auf HomeAssistant.

Allenfalls hilft es ja mal jemand anderem auch weiter.
Vielen Dank jedenfalls nochmals und Grüsse
Radon