Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Radon

#1
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
#2
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  :-\
#3
Ups neue Regeln vergessen.
#4
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.
#5
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  :(
#6
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?
#7
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?



#8
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 ;-)
#9
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.
#10
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
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
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