Probleme ZBF Verkehr zwischen VLANs

Diese Webseite finanziert sich ausschließlich durch freiwillige Spenden. Dank der Unterstützung unserer Nutzer können wir die Inhalte werbefrei und unabhängig anbieten. Jetzt Unterstützen

    Hallo zusammen,

    ich habe gerade zwei nervige Probleme mit der ZBF, zu denen ich etwas Rat bräuchte:

    Probkem 1) ich möchte mit meinen Geräten aus dem einen trusted-VLAN (192.168.1.x) ein Gerät aus dem anderen untrusted-VLAN (192.168.2.x) erreichen. Dazu habe ich eine Policy in der Zone-based-firewall erstellt, die der trusted-Zone vollen Zugriff mit return-traffic auf die untrusted-Zone gewährt. Dennoch erreicht beispielsweise mein iPad aus der trusted-Zone nicht ein Gerät aus der untrusted-zone.

    Problem 2) das Gerät aus der untrusted-Zone soll nur auf einen smb-share aus der trusted-zone zugreifen können. Auch das haut nicht hin.


    Habt Ihr Tipps ?


    Ich poste dazu die entsprechenden policies und eine Gruppe:



    Also zum einen ist die Konstruktion über das Netzwerkobjekt für RFC1918 nicht nötig und in Deiner Konstellation meine ich auch nicht wirklich sinnvoll. Ich würde eher für die jeweilige Regel genau die Netze eintragen, die sie betreffen soll.

    Quote from Blebbens

    Probkem 1) ich möchte mit meinen Geräten aus dem einen trusted-VLAN (192.168.1.x) ein Gerät aus dem anderen untrusted-VLAN (192.168.2.x) erreichen. Dazu habe ich eine Policy in der Zone-based-firewall erstellt, die der trusted-Zone vollen Zugriff mit return-traffic auf die untrusted-Zone gewährt. Dennoch erreicht beispielsweise mein iPad aus der trusted-Zone nicht ein Gerät aus der untrusted-zone.

    Problem 2) das Gerät aus der untrusted-Zone soll nur auf einen smb-share aus der trusted-zone zugreifen können. Auch das haut nicht hin.

    Die häufigsten Probleme hier sind:

    1. Reihenfolge der Regeln nicht beachtet --> Erlaubnisregeln müssen oberhalb von Block-Regeln stehen.

    2. Geräteeigene Firewalls, die Zugriffe aus anderen Subnetzen verhindern


    Zusätzlich: Wenn Du Deine Firewall ausschließlich auf IPv4 beziehst, können Geräte potentiell über IPv6 miteinander kommunizieren, auch wenn sie eigentlich ausgesperrt sein sollten. Dahingehend würde ich mein Regelset überarbeiten.

    Bei den Regeln habe ich definitiv die Allow- vor den Block-Regeln.

    Würde gerne nachhaken:

    Du meinst, man sollte im obigen Screenshot lediglich 192.168.0.0/16 belassen und die beiden anderen Adressbereiche entfernen ?

    Aber, wie sperre ich zusätzlich die entsprechenden IPv6-Bereiche bzw. welche wären das ?

    Zur Policy, die allen Trusted-Geräten den Zugang zur Untrusted-Zone genehmigen soll:

    Hier würdest Du nicht "Destination" auf IP + Object "all private IP-ranges" RFC1918 begrenzen, sondern "ANY/ANY" und zusätzlich von IP-Version "IPv4" auf "Both" ? Dann könnte Trusted komplett auf Untrusted über alle Protokolle hinweg zugreifen ? Die Eingrenzung auf "all private IP-ranges" hatte ich aus einem Tutorial damals übernommen.

    Aber was genau ist an meiner Regel falsch, nach der ein bestimmtes Untrusted-Gerät nur per SMB auf ein bestimmtes Untrusted-Gerät zugreifen darf ?

    Im Screenshot fehlt der Port. Wie sonst kann ich es lösen, dass dieses Gerät nur auf SMB des Trusted-Geräts zugreifen darf ?

    Ich meine, dass keines der Geräte eine eigene (behindernde) Firewall-Regel ausführt.

    Quote from Blebbens

    Du meinst, man sollte im obigen Screenshot lediglich 192.168.0.0/16 belassen und die beiden anderen Adressbereiche entfernen ?

    Nein, ich meine, Du kannst/solltest dieses ja von Dir selbst erstellte Network Objekt komplett löschen. Es ist ein Relikt aus der Zeit vor dem ZBF und wird, von bestimmten besonderen Konstellationen abgesehen, nicht mehr benötigt.


    Quote from Blebbens

    Aber, wie sperre ich zusätzlich die entsprechenden IPv6-Bereiche bzw. welche wären das ?

    Du setzt einfach in jeder Firewall-Regel die Einstellung für die IP-Version auf "both". Bzw. lässt es einfach unangetastet, denn dies ist die Standardeinstellung.


    Quote from Blebbens

    Hier würdest Du nicht "Destination" auf IP + Object "all private IP-ranges" RFC1918 begrenzen, sondern "ANY/ANY" und zusätzlich von IP-Version "IPv4" auf "Both" ? Dann könnte Trusted komplett auf Untrusted über alle Protokolle hinweg zugreifen ? Die Eingrenzung auf "all private IP-ranges" hatte ich aus einem Tutorial damals übernommen.

    Nein, nicht "any". Du wählst ein entsprechendes Netzwerk oder Gerät aus der jeweiligen Zone aus, es sei denn, Du willst wirklich die gesamte Zone miteinbeziehen. In größeren Netzwerken kann es auch hilfreich sein, Geräte nach Typ zu Gruppen zusammenzufassen, dass erspart dann ein bisschen Klick-Arbeit bei der Erstellung von Regeln.

    Mit "Any" kann man gut für Basis-Regeln innerhalb einer Zone arbeiten, z.B. wenn man die lokalen VLANs gegeneinander isolieren möchte.


    Quote from Blebbens

    Aber was genau ist an meiner Regel falsch, nach der ein bestimmtes Untrusted-Gerät nur per SMB auf ein bestimmtes Untrusted-Gerät zugreifen darf ?

    Kann ich aktuell nicht sicher sagen, aber vielleicht gibt es ein Problem mit der Vorlage für SMB in Unifi. Nutze hier bei Port/Service doch mal testweise "any", dann kann man das überprüfen.

    Dann werde ich das network object löschen. Wenn ich denn nun wirklich allen Geräten im trusted-VLAN den Zugriff auf das gesamte untrusted-VLAN gestatten möchte, könnte es doch auf any/any ohne network object komfiguriert werden, oder?


    Werde dann die IP-Version auf „both“ einstellen, aber ganz wichtig:

    Ich blocke die einzelnen VLANs in untrusted gegen alle Gateways außer das eigene und anschließend nur die https/http/ssh-Ports gegen das eigene Gateway. Und das auch wieder nur für IPv4. Wie kann ich untrusted-VLANs gegen die Gateways blocken für IPv4/IPv6? Dazu müsste ich doch die IPv6-Adressen der Gateways kennen. Hier die Block-Policies vorsichtshalber:

    Quote from Blebbens

    Wenn ich denn nun wirklich allen Geräten im trusted-VLAN den Zugriff auf das gesamte untrusted-VLAN gestatten möchte, könnte es doch auf any/any ohne network object komfiguriert werden, oder?

    Ja. Network Objects braucht man wie gesagt eigentlich nur selten und nicht für Basis-Regeln.


    Quote from Blebbens

    Ich blocke die einzelnen VLANs in untrusted gegen alle Gateways außer das eigene und anschließend nur die https/http/ssh-Ports gegen das eigene Gateway. Und das auch wieder nur für IPv4. Wie kann ich untrusted-VLANs gegen die Gateways blocken für IPv4/IPv6? Dazu müsste ich doch die IPv6-Adressen der Gateways kennen.

    Da Du vermutlich keinen statischen v6-Prefix hast, ist das mit dem Kennen der Adressen so eine Sache. ;)

    Blocke doch einfach pauschal die Ports 80 und 443 innerhalb Deiner "untrusted"-Zone, Du wirst dort sicherlich keinen Webserver betreiben, der erreichbar sein müsste.

    DoPe Unifi nennt nur „SMB“ und nur den Port 445, keine weiteren wie 139. Möchte halt, dass der Scanner aus untrusted den Server in trusted einzig per SMB (im shared dolder) erreicht.


    Networker ich möchte erreichen, dass jedes VLAN keinss der anderen VLAN-Gateways erreichen kann. Dabei soll bei jedem VLAN das eigene Gateway für die Ports ssh, http und https gesperrt haben. Sperrt man dem VLAN sein eigenes Gateway, läuft gar nicht mehr, weil die Geräte zB DNS nicht mehr erreichen. Wie oben gezeigt, habe ich für IPv4 umgesetzt. Aber wie mache ich genau das auch für IPv6 ? Das ist das einzige Problem.

    Quote from Blebbens

    Unifi nennt nur „SMB“ und nur den Port 445, keine weiteren wie 139. Möchte halt, dass der Scanner aus untrusted den Server in trusted einzig per SMB (im shared dolder) erreicht.

    Nach meinen Erfahrungen ist es eher das Problem, dass einer von den beiden, meist der Scanner/Multifunktionsgerät, nur SMB 1 spricht.
    So hatte ich einiger Zeit das Problem mit meinem HP MFP M277 bis dann vor einem Jahr endlich eine neue Firmware kam, die auch SMB 3 konnte und nicht nur SMB 1. QNAP und UGreen haben SMB 1 gesperrt/unterstützen es richtigerweise gar nicht mehr.

    phino Ja, der Scanner hat einen Schalter, bei dem sich SMBv1/CIFS aktivieren lässt. Wenn ich den Scanner im selben VLAN wie den Server betreibe, funktioniert es mit und ohne diesen Schalter tadellos. Selber Scanner findet den unRAID-Server aber nicht, wenn er im anderen VLAN steht - trotz meiner Policy, Und aus meinem trusted-VLAN kann ich auch nicht auf den Scanner im untrusted-VLAN zugreifen, obwohl ich aus dem trusted ansonsten auf alle Geräte des untrusted-VLANs zugreifen kann. Das ist doch total bekloppt. Soetwas hatte ich mal mit der Go-VoIP-Box. Dort konnte man dann explizit Zugriffe aus anderen Netzen aktivieren, beim Scanner sehe ich dazu keine Möglichkeit.

    Networker hm, ich hatte mal ein YT-Video geschaut. Der hatte sein IoT-Netz komplett gegen die GATEWAY-Zone geblockt, damit niemand auf das Gateway zugreifen kann. Dann lief aber gar nichts mehr, da auch DNS-Anfragen nicht mehr durchkamen. Wahrscheinlich hatte ich Deinen Vorschlag dann nicht gesehen oder teils nicht verstanden. Bist Du so freundlich und wiederholst den ? Mir ist nämlich nicht klar, wie ich die untrusted-VLANs gegen alle Gateways außer das eigene sperren kann, um dann das eigene nur gegen http/https/ssh zu sparen - und das für IPv4/IPv6.

    Darf ich mich einklinken (der pausche Thread-Titel lässt es m.E. zu)? Ich habe gerade zur ZBF migriert und letztendlich alle Custom Rules entfernt und durch zonen-basierte Verteilung ersetzt. Jetzt bleibt eine Herausforderung:

    Die Netze "LAN" und "WORK" sind beide in "internal" und dürfen somit ungehindert miteinander kommunizieren. Aber - in WORK befinden sich die Geräte der Arbeitgeber fürs Home Office (Laptops und Telefone) und die sollen nicht pauschal mit LAN kommunizieren dürfen, sondern nur ins Internet und ein einzelnes Gerät (einen Drucker) in LAN ansprechen.

    Wie modelliere ich das?

    Ist eine Gateway IP nicht gesperrt, dann ist das fehlen der Sperre einer anderen IP des Gateways Makulatur.

    Wenn Du an einem Haus 3 von 4 Außentüren abschliesst, kann man durch die 4. Tür immernoch ins Haus und sich dort frei bewegen.

    Also einfach auf allen 80, 443 und 22 sperren. Denk dran dass Du ggf. auch mal lokal von irgendeinem Gerät konfigurieren können musst.

    Quote from DoPe

    maxim.webster du könntest natürlich die beiden Netze in eigene Zonen packen.

    Nee ..

    Quote from DoPe

    Ansonsten backst Du bei Internal - Internal entsprechende Regeln und benutzt zusätzlich zu Source und Drstination Internal, jeweils die IP Netze.

    Genau, aber ein Teil fehlt da noch, denn -

    • ich habe jetzt eine Regel, welche WORK die Kommunikation mit allen Netzwerken in der gleichen Zone außer WORK verbietet.
    • ich habe eine 2. Regel, welche WORK die Kommunikation mit einer IP in LAN erlaubt (der Drucker)

    Problem jetzt: Ich kann aus LAN keine Verbindungen mehr nach WORK aufbauen, vermutlich weil WORK lt. Regel nicht antworten darf.

    Und während ich darüber schreibe, komme ich selbst auf den "Trick", dass man in der Regel nur "New"-Traffic blockieren darf, aber Established und Related zulässt.

    Somit sieht die Regel für "Netz zu anderen Netzen in gleicher Zone" (am Beispiel PHONE) jetzt so aus:

    Quote from DoPe

    Ist eine Gateway IP nicht gesperrt, dann ist das fehlen der Sperre einer anderen IP des Gateways Makulatur.

    Dazu auch eine Frage: Ich habe eine Regel angelegt, um für alle Netze in "internal" außer LAN den Zugriff auf die Ports 80,443 und 22 des Gateways (UDM Pro) zu sperren. Leider wird bei aktivieren der Regel auch der Zugriff von LAN auf das UDM Pro UI gesperrt, nur noch via App und damit vermutlich via ui.unifi.com geht noch.

    Wo liegt der Fehler?

    maxim.webster Ich hab mal geschaut. Musste etwas such um einen Standort zu finden, an dem ich den Zugriff aus den Netzen auch Remote nochmal abchecken konnte. Hatte kurzzeitig mal ein weiteres LAN der Zone INTERNAL in die Regel aufgenommen und der Zugriff klappte nach wenigen Sekunden. Nach dem entfernen und dem Session timeout war der Zugriff blockiert.

    Sieht genauso aus wie bei dir. Mein Network Unifi entspricht deinem LAN und ist das Netzwerk, aus dem man auf die GUI zugreifen kann. Das Firewall Objekt für Destination ist eine Portgruppe mit 22, 80 und 443.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login