Hallo Leute
Ich bin seit ein paar Wochen Besitzer einer DEC740.
Nun ich dachte eigentlich, ich hätte das ganze Verstanden wie die Regeln funktionieren und quasi alles funktioniert auch wie ich es gern hätte. Aber ich habe noch zwei Baustellen die ich einfach nicht hinbekomme und ich kein Ausweg finde ohne hier mal zu Fragen :(
Ich versuche möglichst kurz die Probleme zu schildern, die ich nicht verstehe und gelöst kriege.
Aufbau:
Internet
:
: Provider
:
.-----+-----.
| Router |
'-----+-----'
|
WAN | 192.168.1.0/24
|
.-----+------. DMZ .------------.
| OPNsense +----------------------+ DMZ-Server |
'-----+------' 192.168.200.0/24 '------------'
|
VLAN 20 + VLAN 30 | 192.168.20.0/24 + 192.168.30.0/24
|
.-----+------.
| LAN-Switch |
'-----+------'
|
...-----+------... (Clients/Servers)
DEC740 FW: 24.7.7 (vorher 24.7.4 und ältere identisches Verhalten)
WAN: 192.168.1.0/24 (hinter einem Router der leider keine Modemfunktion hat)
DMZ: 192.168.200.0/24 (z.B. Unifi Controller)
vlan20: 19.168.20/24 (z.B. Pi-Hole und HomeAssistant)
vlan30: 19.168.30/24 (z.B. Smartphones)
Kein NAT ist aktiv, abgesehen von Standard nach WAN und Port Forward von WAN an das NAS. Da funktioniert aber alles wie es soll.
Phänomen 1:
Mir werden im "Firewall: Log Files: Live View" extrem viele Pakete angezeigt mit der Regel "Default deny / state violation rule". Viele sind auch gerechtfertigt, aber sehr viele verstehe ich eben nicht, da ich Regeln habe die es zulassen sollten. Seltsamerweise funktioniert die Regel ab und zu, aber meist nicht.
Ein Bsp.: Die Regel funktioniert 1-mal aber auf einem anderen Source Port nicht, obwohl die Regel jeden Source Port akzeptieren sollte.
Bilder "Live View _ Log Files_1" + "Firewall_Rule_1"
https://drive.google.com/file/d/1bLimOsnXOLKWdlbIV2I91r8teJAvS3oR/view?usp=sharing (https://drive.google.com/file/d/1bLimOsnXOLKWdlbIV2I91r8teJAvS3oR/view?usp=sharing)
Das gleiche habe ich mit ganz vielen anderen Regeln auch auf allen Netzwerken (diese konnte ich per Zufall schön aufzeichnen). Seltsamerweise "reklamieren" die Geräte aber nicht sie hätten kein Internet oder ähnliches, z.B. der Unifi Controller kann Geräte-Updates herunterladen (dann kommen ganz viele grüne Einträge über diese Regel).
Phänomen 2:
Mit einem von 2 Smartphones komme ich nicht auf HomeAssistant, das andere geht problemlos. Ich habe mit dem "Interfaces: Diagnostics: Packet Capture" aufgezeichnet auf vlan30 und vlan20 gleichzeitig. Die Pakete gehen zuerst durch die Firewall zum HA (von vlan30 nach vlan20) und die Antwort kommt auch wieder zur Firewall zurück am vlan20, nur werden sie nicht mehr am vlan30 ausgegeben.
Bild: "Packet_Capture_vlan20_vlan30"
https://drive.google.com/file/d/1ZZB2ep78XUE4_T70P1pP-J_e3gxfZRpu/view?usp=sharing (https://drive.google.com/file/d/1ZZB2ep78XUE4_T70P1pP-J_e3gxfZRpu/view?usp=sharing)
Nebenbei ist noch zu erwähnen: Das gleiche Smartphone kann Namen auflösen via Pi-Hole das ja auch im vlan20 ist oder auch auf sonst alle Geräte zugreifen kann die im vlan20 sind. Es kommt auch keine Blockierungsmeldung im Firewall Log.
Kann mir irgendjemand sagen, wo ich noch eine falsche Konfiguration suchen sollte? :-[
Sorry, die Bilder waren leider zu gross um sie hochzuladen. In ganz schlechter Qualität trotzdem auch angehängt.
Danke euch und viele Grüsse
Radon
Liebe Grüße!
Versuche dies mal mit Folgenden Konfigurationen als Beispiel!
Bei FTP gibst du entweder als "other" die Ports an, oder du vergibst dort den Alias wo du die Ports für das Gerät drin hast.
Dann bei Redirect Target IP die IPV4 IP von dem Gerät (LocalIP z.B. 192.168.1.119 herausfindbar bei Windows über cmd ipconfig)
Protocol jeweils Protocol auswählen, TCP oder UDP. Unten dann bei Filter Rule Association auf Pass stellen.
Melde dich gerne Zurück wenn es funktioniert hat!
Sind das alle FW Regeln, die wir da sehen?
Falls Du kannst, formuliere das Problem mal um:
Statt einer Pass Regel für nicht lokale Netzwerke, bilde
1) eine Pass Regel für Traffic zur FW selbst
2) eine Block Regel für Traffic mit Ziel "lokale Netzwerke" gefolgt von
3) einer Regel, die alles erlaubt.
Der Unterschied ist, dass Deine Lösung auch Verkehr mit der FW selbst verhindert. Warum Pakete trotzdem mal durchgelassen werden und mal nicht, verstehe ich allerdings auch nicht. Könnte an den Aliases liegen. Ich beobachte so ein Verhalten auch mit Hosts, die bei jeder DNS Query eine andere Adresse zurückliefern, weil der Paketfilter der FW die IP Adressen vergleicht.
Zu Problem 2 müsstest Du die FW Regeln angeben.
Mit fällt gerade auf beim Packet Logger das die Pakete 2 mal an verschiedene Local IPs gehen, kann es sein das du die Ports für mehrere Geräte freigegeben hast?
Hatte das zuletzt bei mir wo ich der Fritzbox alle Portfreigaben gegeben hatte, und für meinen Storage Server die FTP Ports. OPNSense weiß nicht wohin dann damit wodurch die Verbindung nicht aufgebaut wird.
Port 443 soll an den Unify Server gehen fürs Webgui
geht Port 443 noch wo anders hin als Forward?
Wenn JA dann Forward fürs andere Gerät raus, Wenn NEIN dann überprüfe mal ob du nicht eine Weiterleitung ihrgendwo drin hast.
Kommt mir sehr bekannt vor von den Bildern.
Hallo mooh und Xheberiotion
Danke vielmals für euren Input.
@Xheberiotion:
Ich vermute du meinst ein Port Forwarding das ich einstellen soll. Leider verstehe ich nicht wie mir dies weiterhelfen soll für eines meiner Probleme.
Das Thema 1 Bsp. vom UniFi ist ja DMZ nach WAN (klassischer Internet Zugriff über 443) und Thema 2 ist vlan30 nach vlan20.
Zudem im Packet Logger sind nicht 2 verschiedene IPs. Es sind einfach mehrere Anfragen von 192.168.30.133 (Smartphone) nach 192.168.20.202 (HomeAssistant). Im Logger rechts sieht man, dass HA Antworten zurücksendet und an der Firewall am vlan20 ankommen. Links sieht man dass diese Antworten aber nicht im vlan30 weitergeleitet werden an das Smartphone. Sprich von vlan30 nach vlan20 funktioniert (alle Telegramme links und rechts vorhanden), aber die Antwort geht nicht mehr zurück (was eine Firewall/Router immer automatisch tun sollte).
@mooh:
Habe ich so mal versucht umzustellen. Auf anraten von ChatGPT habe ich anschliesend auch noch alle aktiven States gelöscht.
Eine Floating Regel "Alle Geräte in Home Netzwerken auf diese Firewall" hatte ich schon vorher drin (dein Punkt 1).
Ich habe die Regel nun geändert auf eine "Unifi block local HTTPS" und "Unifi Pass all HTTPS" (deine Punkte 2+3).
Im Log sieht es aber immer noch in etwa gleich aus. Zum Test habe ich Updates auf dem Unifi Server gemacht (Ubuntu und anschliessend Reboot 9:23 - 9:32)
Was ich nicht ganz verstehe ist deine Aussage zum Host der DNS Query mit unterschiedlichen IP's beantwortet??
Zur vollständigkeit noch die restlichen Regeln in einem separaten Beitrag (wegen der Grösse).
Und noch weitere Beispiele von geblockten Telegrammen und Kommentaren welche Regel die eigentlich freigeben sollten.
Neben den Kommentaren im Bild noch ein paar Details zu meinen Aliases:
All_privat_Networks = 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 127.0.0.0/8
UniFi_Controller = 192.168.200.211
T_Gerate = z.B. 192.168.30.118 + 192.168.30.111
M_Gerate = z.B. 192.168.30.133
Die Regeln "Default allow LAN to any rule" will ich eigentlich noch los werden und gezielte Regeln einrichten, aber momentan mit diesen "falsch" geblockten, ist es schwer zu unterscheiden ob ich schon eine Regel habe oder nicht.
Und nochmals als Kommentar zu meinem Phänomen 1: Ich habe kein Gerät das durch diese geblockten Telegramme wirklich ein Problem hat. Die Kommunikation ins Internet funktioniert.
Gibt es irgend eine Einstellung/Regel die "passiven Traffic" blockt?
Die einzige Kommunikation die nicht funktioniert ist mein Phänomen 2. Das betrifft aber nur 192.168.30.133, nicht aber 192.168.30.118. Ich denke nicht dass die Firewall hier das Problem ist, da wird auch nicht geblockt.
Ich danke für jeden Input, der mich weiter bringt ;-)
Ich würde gerne weiter helfen, verliere aber den Überblick. In meiner Gedankenwelt stelle ich mir erstmal die Frage, wozu brauche ich ein Netzwerk eigentlich. Dann kann man anfangen, die Regeln für dieses Netzwerk hinzuschreiben (z.B. keine Verbindungen in andere Subnetze initiieren). Dann kommen die Host-spezifischen Regeln, z.B. DMZ Server X darf mit Server Y in einem anderen Subnetz reden und als Letztes kommt dann Refactoring ala Regeln umverteilen, Interface-Gruppen bilden und Aliases einfügen.
Nach jedem Schritt kann man dann die Ergebnisse prüfen, und weil man immer nur an einer Schraube gedreht hat, ist auch klar warum etwas nicht mehr funktioniert.
Naja, das habe ich schon auch gemacht. Und aus meiner Sicht machen die Trennungen und Regeln auch Sinn. Aber ich bin verwirrt über die Einträge und verstehe sie nicht. Ich kenne das bisher von keiner einzigen Firewall die ich bisher in den Händen hatte und würde das gerne verstehen ???
Je länger ich nachschaue umso mehr bin ich überzeugt, es kann gar nicht an den Regeln an sich liegen. Die tun schon was sie sollen. Aber es muss irgend eine sonstige Globale Einstellung sein.
Ich finde zu jedem dieser "unerwarteten" Block Einträge auch ein identischen Pass Eintrag der ca. 30-60 min vorher zugelassen wurde.
Also Quell und Ziel IP sowie Ports, siehe erneut Anhang. Das kann kein Zufall sein oder falsche Regelkonfiguration.
Könnte mir allenfalls irgend eine der Einstellungen helfen? Z.B. Firewall Optimization? Ich kenne mich da noch gar nicht aus.
Oder könnte es damit zusammenhängen, dass bei jedem dieser Blocks auch immer mindestens zwei identische Einträge miteinander auftauchen?
Quote from: Radon on October 30, 2024, 08:58:13 PM
Ich finde zu jedem dieser "unerwarteten" Block Einträge auch ein identischen Pass Eintrag der ca. 30-60 min vorher zugelassen wurde.
Also Quell und Ziel IP sowie Ports, siehe erneut Anhang. Das kann kein Zufall sein oder falsche Regelkonfiguration.
Vermutlich sind es lediglich Verbindungs-Timeouts.
Und vermutlich betrifft das auch immer dieselben Geräte mit denselben Zielen, wahrscheinlich IoT Geräte, die Verbindungen zu einem Server ewig halten wollen. Können sie auch, aber dafür müssten sie ab und zu ein Paket drüber schicken.
Wenn die Verbindung auf der Firewall geschlossen ist, muss das Gerät eben eine neue aufbauen, wenn es wieder das Bedürfnis überkommt, dem Server was mitzuteilen.
Quote from: Radon on October 30, 2024, 08:58:13 PM
Ich finde zu jedem dieser "unerwarteten" Block Einträge auch ein identischen Pass Eintrag der ca. 30-60 min vorher zugelassen wurde.
Also Quell und Ziel IP sowie Ports, siehe erneut Anhang. Das kann kein Zufall sein oder falsche Regelkonfiguration.
Die haben das wahrscheinlich nicht geloggt.
Das Logging der Default Deny Regel kannst du auch auf OPNsense ausschalten, wenn du die Einträge nicht sehen möchtest.
Hallo viragomann
Danke dir vielmals!
Und ja das kann ich mir auch gut vorstellen und erklärt alles von meinem Phänomen 1.
Hast du mir einen Tipp wie ich mit einer eigenen Regel "Block_All_to_All" alles blockierte loggen kann, aber solche "Timeouts" nicht?
Und hast du allenfalls auch eine Idee zu meinem Phänomen 2 wo nicht zurück geroutet wird?
Quote from: Radon on October 30, 2024, 10:14:45 PM
Hast du mir einen Tipp wie ich mit einer eigenen Regel "Block_All_to_All" alles blockierte loggen kann, aber solche "Timeouts" nicht?
Loggen kannst du das mit eine eigenen Block-alles Regel am Ende des Regelsets mit aktiviertem Logging.
Und das Logging der Default-Deny Regel kannst du ausschalten:
Firewall: Settings: Advanced > Logging: Default block
Quote from: Radon on October 30, 2024, 10:14:45 PM
Und hast du allenfalls auch eine Idee zu meinem Phänomen 2 wo nicht zurück geroutet wird?
So wie du das darstellst, dass die Antwortpakets am VLAN20 Interface zurückkommen mit einer Ziel-IP im VLAN30, an diesem Interface aber nicht raus kommen, bin ich ratlos. Wenn die Smartphones gleichzeitig problemlos Internet-Zugriff haben, kann man eigentlich alle potentiellen Fehler ausschließen.
Antwortpakete werden aufgrund eines durch das initiale Paket gesetzten States durchgelassen.
Du kannst dir den State für die Verbindung ansehen: Firewall: Diagnostics: States
Da kannst du nach Ziel- od. Quel-IP filtern. Jede Verbindung verwendet einen bestimmten Port an den Interfaces, und für jede müsstest du 2 Einträge sehen, in und out.
Kannst du von einem anderen Interface darauf zugreifen?
Es wäre für mich logischer, wenn der HA gar nicht auf Anfragen von außerhalb des eigenen Subnetzes antwortet, weil er entweder keine oder eine falsche Gateway Einstellung hat oder es selbst mit seiner Firewall blockiert.
Quote from: viragomann on October 30, 2024, 10:53:58 PM
Loggen kannst du das mit eine eigenen Block-alles Regel am Ende des Regelsets mit aktiviertem Logging.
Das habe ich versucht, leider loggt es mir nun einfach all diese vermutlichen Verbindungs-Timeouts auf meine Regel anstelle der Default Deny. Finde es immer noch seltsam funktioniert das bei einer block Regel, aber nicht bei den pass Regeln...
Daher ich versuche nochmals kurz zu erklären was ich möchte:
Ich will geblockten Datenverkehr loggen und sehen.
Aber nicht von Verbindungen die ich zugelassen habe (wie diese vermutlichen Verbindungs-Timeouts).
Ich kriege das leider nicht hin. :-[
Problem 2 konnte ich lösen, auch wenn ich es nicht verstehe wieso. Wenn ich diesem Smartphone eine andere IP gebe, dann funktioniert das Routing und FW wie gewohnt.
Habe nun die IP 192.168.30.132 anstelle von 192.168.30.133 gegeben. Es gibt keine unterschiedlichen FW Regeln oder Aliasse wo die eine IP drin ist und die andere nicht, daher verstehe ich nicht wieso es mit der anderen IP geht, was mir einfach ein schlechtes Gefühl hinterlässt zu der gesamten Firewall :(
Quote from: Radon on November 03, 2024, 02:58:31 PM
Daher ich versuche nochmals kurz zu erklären was ich möchte:
Ich will geblockten Datenverkehr loggen und sehen.
Aber nicht von Verbindungen die ich zugelassen habe (wie diese vermutlichen Verbindungs-Timeouts).
Ich kriege das leider nicht hin. :-[
Hast du nun den Haken bei
Firewall: Settings: Advanced > Logging: Default block rausgenommen?
Ich würde erwarten, dass Verbindungs-Timeouts (state violations) damit nicht mehr geloggt werden.
QuoteProblem 2 konnte ich lösen, auch wenn ich es nicht verstehe wieso. Wenn ich diesem Smartphone eine andere IP gebe, dann funktioniert das Routing und FW wie gewohnt.
Habe nun die IP 192.168.30.132 anstelle von 192.168.30.133 gegeben.
Vielleicht ein IP Konflikt?
Wenn es nicht funktioniert, mal überprüfen, ob in der ARP Tabelle (Interfaces: Diagnostics: ARP Table) die korrekte MAC Adresse steht.
Quote from: viragomann on November 03, 2024, 08:17:09 PM
Hast du nun den Haken bei Firewall: Settings: Advanced > Logging: Default block rausgenommen?
Ich würde erwarten, dass Verbindungs-Timeouts (state violations) damit nicht mehr geloggt werden.
Ja, ich habe "Default block" entfernt. Bzw. es spielt nun keine Rolle ob ich das mache oder nicht. Gleiches Resultat.
Die Pakete die vorher in dieser "Default deny / state violation rule" geloggt wurden, werden nun einfach in meiner neuen Regel geloggt.
Ich habe eine "Block All" Regel hinzugefügt in den Floating Rules damit ich trotzdem "den Rest" loggen kann und zur demonstration nochmals oberhalb eine Pass Regel auf Port 443. Siehe neue Screenshots. Diese Regeln sind ganz am Ende der Floating Rules.
Und 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.
Gibt es nirgends eine Einstellung "geh strikt nach Regel und überwache nicht Verbindungszustände"? Ist mir doch egal ob diese "tote Verbindung" weiterhin besteht oder nicht. Diese Geräte sollen auf diesem Port frei kommunizieren können wenn ich das so definiere.
Quote from: viragomann on November 03, 2024, 08:17:09 PM
Vielleicht ein IP Konflikt?
Wenn es nicht funktioniert, mal überprüfen, ob in der ARP Tabelle (Interfaces: Diagnostics: ARP Table) die korrekte MAC Adresse steht.
Hab ich gecheckt, passt und kein IP konflickt. Ping geht auch in beiden Fällen (natürlich nur gerade die aktive IP). Es ist nur dieser HomeAssistant Server den ich nicht erreiche.
Alles andere sowie auch Internetzugriff funktioniert mit beiden IPs, und dazu muss das Smartphone auch DNS im "20-er" Netz abfragen und das funktioniert einwandfrei mit beiden IPs.
Mal vielleicht in eine ganz andere Richtung gedacht:
Ich habe zu beginn beim Installieren einige Interface mehrmals angelegt und gelöscht. Bridges, VLANs, usw. bis ich es irgendwann so hatte wie ich es gern hätte. Könnte es sein, dass ich im Hintergrund irgendwas aus versehen "kaputt" gemacht habe? ???
Oder nochmals einen anderen Gedanken: könnte es ein Problem mit dem Interface/Treiber sein?
Ich habe physikalisch alle internen Netzwerke als VLANs auf der 10GBit Schnittstelle. Nur das WAN ist separat auf der zweiten 10GBit Schnittstelle ohne VLAN.
Auf den Switchen ist der Fehler jedoch sicher nicht, denn vorher hatte ich einen anderen Router jedoch VLANs usw. war alles schon identisch zuvor.
Ups neue Regeln vergessen.
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=4758.0)
https://forum.opnsense.org/index.php?topic=20219.0 (https://forum.opnsense.org/index.php?topic=20219.0)
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html (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