Firewall / Routing funktionieren nicht wie erwartet.

[Radon]

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:

Code: [Select]

      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

[Xheberiotion]

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!

[mooh]

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.

[Xheberiotion]

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.

[Radon]

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.

[Radon]

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 ;-)

[mooh]

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.

[Radon]

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?

[viragomann]

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.

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.

[Radon]

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?

[viragomann]

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

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.

[Radon]

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 

[viragomann]

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.

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.

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.

[Radon]

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.

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.

[Radon]

Ups neue Regeln vergessen.