Regel für "Internal" blockiert externen Traffic

    Hallo zusammen,

    ich habe in einem auf ZBF umgestellten Kundennetzwerk ein merkwürdiges Phänomen. Die klassiche "block inter VLAN traffic"-Regel heißt bei mir im ZBF "Block: Internal --> Internal". Ihre Konfiguration ist simpel:


    Nur erhalte ich im Log allerdings über viele Clients folgende Meldung:

    Code
    $Gerät was blocked from accessing 100.102.8.6 by firewall policy: Block: Internal --> Internal

    Die 100.102.8.6 ist eine legitime Adresse, und diese Kommunikation absolut erwartet. Ich frage mich nun aber: Wie kann es sein, dass eine eine IP-Adresse aus dem Internet von meiner "VLAN-Regel" betroffen ist? Habe ich irgendwo einen Denkfehler oder ist das ein Bug?

    Im Einsatz ist hier eine UDM Pro unter Firmware 4.1.13 mit Network 9.0.114.

    Hmm ... also irgendwie ist die Firewall erstmal der Meinung, die IP wäre in der Zone internal ... dann wäre das Blocken auch korrekt. Aber ich vermute mal, dass Du nicht fragen würdest, falls Du die IP oder ein Subnet mit der IP irgendwo zweckendfremdet hast.

    Was ist denn wenn Du für die RFC1918 Netzwerke ein Firewall Objekt anlegst und dieses als Source und Destination IPs setzt. Wird das dann auch noch geblockt oder gehts dann wenigstens erstmal?

    Nein, genau, die besagte Adresse ist in keinem Firewall-Objekt enthalten. Diese Adresse ist aus unserer Sicht auch schlicht "Internet", wir verfügen nicht darüber, wissen lediglich, dass sie zu einem Software-Anbieter gehört, dessen Produkt genutzt wird. Das "RFC1918"-Objekt hatte ich beim Wechsel auf ZBF gelöscht, aktuell gibt es nur zwei Objekte, die interne Geräte abbilden (10.100.100.50 bzw. .60).

    Aktuell weiß ich tatsächlich nicht mal, ob sich aus diesem Thema hier tatsächlich ein praktisches Problem für die Nutzer ergibt, noch steht mein Telefon still. ;)

    Aber auch wenn es vielleicht nur eine verbuggte Anzeige ist, etwas genauer Wissen würde ich es schon wollen.


    Ich werde mal Deinen Ansatz verfolgen und das RFC1918-Objekt wiederbeleben.

    Quote from DoPe

    Naja evtl. fragt die Software nach Update oder gar Lizenzen

    Nicht ganz, es geht hier um KIM, das ist Email mit ein bisschen Verschlüsselungsvoodoo speziell für's Gesundheitswesen. Praxen, Krankenkassen, Apotheken und sonstige Leistungserbringer kommunizieren damit untereinander (gemäß politischem Willen immer, in der Praxis zumindest immer dann, wenn das Faxgerät gerade klemmt).

    Eine Besonderheit bei KIM und damit vielleicht auch ein Ansatz zur Lösung dieses Rätsels hier: Jede Organisation benötigt einen "KIM-Client". Dies ist im Prinzip ein Mini-Mailserver, der lokal im Netz von den Systemen angesprochen wird, die KIM-Nachrichten verarbeiten. Gleichzeitig kommuniziert der KIM-Client nach außen mit dem tatsächlichen Postfach-Anbieter, das ganze Zeug ist (natürlich) Cloud-basiert.

    In diesem konkreten Fall geht es um kleinstmöglichen Praxen: Ein Behandler, ein Computer. Der KIM-Client läuft also auf der selben Maschine wie die Software, die KIM letzlich dem Nutzer zur Verfügung stellt. Aus Sicht dieser Software ist es also immer eine Verbindung gegen "Localhost", also tatsächlich RFC1918.

    Ich muss mich nochmal einlesen, was genau der KIM-Client dann veranstaltet. Fakt ist jedenfalls, dass vor der ZBF-Umstellung keine Block-Einträge protokolliert worden sind, das habe ich nochmal explizit nachgeprüft.

    Moin :-)

    Quote from Networker

    Die 100.102.8.6 ist eine legitime Adresse

    10.64.0.0/10 also 10.64.0.0 bis 100.127.255.255 ist der IPv4 Prefix for Shared Address Space

    Bekannt dafür das diese gerne und oft viel von Providern als CGNAT Adresse benutzt wird. Aber halt nicht ausschließlich für CGNAT benutzt wird sondern auch für andere Dinge benutzt wird z.B als privater IP der nicht aus RFC1918 Adressen besteht und damit zu fast 100% Konfliktfrei ist. (Unifi macht was ähnliches mit dem 203.0.113.0/24 Bereich der für Test und Docu gedacht ist für die Intenren DNS Server auf einem UnifiOS Gerät)

    Quote from Networker

    Nicht ganz, es geht hier um KIM

    Na gut das du das sagts.. Vorweg ich kenn den kram nur eher Oberflächlich weil null Berührungspunkte. Wenn ich aber richtig Google ist "100.102.8.6" die generische IP vom Mailsserver. Die Verbindung zu diesem muss über den Konektor laufen. Macht auch sinn den der baut das VPN zur Cloud auf... Dazu sind dann halt ggf. Routen anzulegen das die Ip über den Konnektor läuft.

    Nun hast du die freie Auswahl. Konnektor in einem anderen VLAN ? Dann ist es der Transfer Traffic der geblockt wird oder alte Routen die noch existieren auf dem KIM Client die halt irgentwo hinzeigen aber ungültig sind. (und dann die Aktuelle richitge Route greift)

    Mit diesem KIM Dreck haben wir auch ständig zu tun, allerdings überall Sophos Firewalls oder Securepoint. Den KIM Mailversand kann man ja testen, funktioniert der denn?

    Mein Netzwerk

    Internet:

    Glasfaser TNG 1 Gigabit Synchron

    Speedtest

    Unifi Komponenten:

    UCG Fiber

    USW-Lite-8-PoE

    3x USW-Flex-Mini

    UAP-AC-Lite

    2x U6-Lite

    UVC-G3-FLEX

    2x UVC-G3-Instant

    1x UVC-G4-Instant

    UVC-G5-Bullet

    Sonstige Hardware:

    QNAP TS-453a als Backup

    Thinkstation mit Unraid, VM 3CX, Pihole + Unbound, Home Assistant usw.

    PC mit Ryzen 3700x, 16GB 3200 Ram, Ati Radeon 5700X, 2x M.2 SSD und 1x SATA SSD

    Moin, versuche mal bitte in der Regel das blocken nur auf neu und ungültig umzustellen. So weit ich weiß wird mit der Regel mit alles hin und Rückweg und jede neue Freigabe geblockt, ausnahmslos.

    Mann hat es nicht leicht, aber leicht hat es einen..

    External Content beta.ubiquiti-networks-forum.de
    Content embedded from external sources will not be displayed without your consent.

    Besten Dank Euch allen schon mal für die konstruktive Beteiligung und sorry, dass meine Antwort etwas dauerte!

    Ich habe das Ganze näher untersucht und beobachtet. gierig war schon sehr auf der richtigen Spur und ich ärgere mich etwas, dass ich nicht von Anfang an schon einen Schritt weiter gedacht hatte.

    Die Situation/Struktur ist folgende: 10 kleine Praxen sind unter einem Dach zu einer Praxengemeinschaft zusammengeschlossen. Netzwerktechnisch teilen sie sich den Internetzugang, die Backup-Infrastruktur und den Konnektor (ein VPN-Gateway über das Praxen an die Telematik Infrastruktur, also die "Gesundheitswesen-Cloud", angeschlossen werden. Jede Praxis hat also ihr eigenes, abgeschottetes Subnetz, der Konnektor befindet sich in einem "Gemeinschaftsnetz" und ist für alle erreichbar. Es gibt drei statische Routen, die Anfragen in bestimmte Subnetze (unter anderem 100.102.8.0/24) durch den Konnektor leiten. Dieses gesamte Konstrukt lief mit der klassischen Firewall seit über drei Jahren unauffällig.

    Ich habe nun festgestellt, dass in der Tat sämtlicher Pakete, die sich auf die drei statischen Routen beziehen, von der Firewall verworfen werden, das ganze also weitreichender ist, als zunächst vermutet. gierig : Wir sind hier ja in genau dem von Dir beschriebenen Szenario. Ich verstehe nur nicht, was Du mit "Transfer Traffic" meinst. Kannst Du das näher erklären?


    Quote from Naichbindas

    Moin, versuche mal bitte in der Regel das blocken nur auf neu und ungültig umzustellen. So weit ich weiß wird mit der Regel mit alles hin und Rückweg und jede neue Freigabe geblockt, ausnahmslos.

    Hmm, das verstehe ich ehrlich gesagt nicht. Ich möchte ja, dass die einzelnen Praxisnetze vollständig gegeneinander isoliert sind. Die Regeln, dass die Einzelpraxen mit dem Konnektor reden dürfen und umgekehrt, stehen natürlich oberhalb der "Block any-->any"-Regel. In wieweit meinst Du, die Connection States könnten da eine Rolle spielen?

    Networker Ja ich bin da erst auch nicht ganz durch gestiegen.

    Also ich habe es bei mir so gemacht:




    Das ganze hatte ich vorher das unter Connection State auch alle hatte. Dann hatte ich massiv Probleme nachträglich eine Freigabe hinzubiegen und so weiter.

    Auch Rückwege waren dann nicht mehr möglich.

    Mit der Einstellung jetzt erreiche ich das diese Firewallregel nur abgeglichen wird wenn ein Gerät eine neue Verbindung aufbaut zu einem anderen VLAN / Netzwerk oder eine Verbindung nicht mehr gültig ist und dann verworfen wird.

    Somit bleibt der Weg für Erstellt, also Freigaben die ich später einrichten will und auch der Rückweg sowie bei Entsprechend etwas zutrifft dann mache das nicht was die Firwallregel sagt, also zu machen.

    Und siehe da ich konnte erstmal mit dieser Regel inter VLAN aussperren und dann weitere Regeln erfolgreich etablieren.

    Vlt erinnerst du dich noch wie es früher war.

    Da hatten wir für LAN ein IN ein OUT und ein LOKAL.

    Da mussten wir eine Regel für den Hinweg schaffen und einen für den Rückweg und evtl auch mal eine Regel für InterVLAN und so weiter.

    Das ganze machst du jetzt in der ZBF nur mit einer Regel, auch kannst du dort den Rückweg mit reinbringen.

    Die Arbeit soll dadurch ja leichter werden. :P

    Vlt hilft dir diese Grafik etwas dabei:


    Links ist wie es früher war und in der zweiten und dritten Zeile sind die Punkte wohin die ZBF greift.



    Das alles machst du ja jetzt mit nur einer Regel dann, also LAN IN und LAN Out. Daher kannst du auch nicht die Regel in Connection State auf alles ansetzen zum Blockieren.

    Und ja falls die Frage kommt, auch ich hatte vorher auf alle und die erlauben Regeln vor blockieren und es ging trotzdem nicht.

    Kann vlt sein das durch ein Update bei Unifi wieder geändert wurde aber bis dato hatte ich das nur hinbekommen so wie ich es beschrieben hatte.

    Ich hoffe ich konnte es einigermassen erklären und es ist ein versuch wert.

    Falls du damit nicht zufrieden bist kannst du ja trotzdem jederzeit wieder auf all stellen.

    Mann hat es nicht leicht, aber leicht hat es einen..

    External Content beta.ubiquiti-networks-forum.de
    Content embedded from external sources will not be displayed without your consent.

    Danke für die Erläuterungen! Ich habe Dich prinzipiell schon verstanden, mir fehlt nur der ganz konkrete Bezug zu meinem Problem.

    Es gibt in diesem Netzwerk kein generelles Kommunikationsproblem (Thema "Hinweg" und "Rückweg"). Bei der Kommunikation mit dem angesprochenen Konnektor stehen beide eingerichteten Erlaubnis-Regeln oberhalb der generellen Block-Regel, daher spielt es für diese Kommunikation keine Rolle, was genau in der Block-Regel steht.

    Mein Problem liegt darin, dass der Verkehr für die statischen Routen ins Internet von der Block-Regel weggefiltert wird und ich den Zusammenhang nicht verstehe. Letztenendes verstehe ich auch nicht, warum meine Blockregel im ZBF-Konzept offenbar mehr tut, als die "RFC1918"-Regel früher. Prinzipiell sollten sie dasselbe bewirken, aber ganz offensichtlich ist es nicht so... :/

    Quote from DoPe

    Wieso nicht alles blocken? Das was man will wird freigegen und das vor dem alles blocken...

    Das ging früher so und auch heute mit zbf. Solche Probleme konnte ich bei keiner Version feststellen Naichbindas

    Das dachte ich auch und bei mir ging es jedenfalls nicht. Das sagte ich ja auch. Wie man es kennt eine InterVLAn Blockregel erstellen und danach die Freigaben erstellen und die erlauben vor dem blockieren schieben.

    Das alles ist keine Kunst, aber ich hatte damit bei mir nur erreicht das solange die InterVLAN Block regel an war obwohl die am Ende der Liste war nach dem erlauben, die erlauben Regeln irgendwie nix gemacht haben.

    Erst nach dem ich die blockieren Regel deaktiviert hatte, dann so wie ich an verschiedenen Stellen im Internet gelesen hatte wie es andere gemacht haben mit dem Neu und ungültig ging es auch bei mir wieder.

    Aber habe es seitdem es so bei mir läuft auch nicht wieder anders herrum probiert, werde ich morgen mal testen.

    PS: Diesen Hinweis hatte ich wörtlich genommen:

    Quote

    Hinweis

    Es ist wichtig, nur den New- und Invaliden-Verbindungszustand zu blockieren. Sonst blockieren Sie auch den Rückverkehr von jeder zulassenden Politik, die Sie später erstellen könnten!

    Quote from Networker

    Mein Problem liegt darin, dass der Verkehr für die statischen Routen ins Internet von der Block-Regel weggefiltert wird und ich den Zusammenhang nicht verstehe. Letztenendes verstehe ich auch nicht, warum meine Blockregel im ZBF-Konzept offenbar mehr tut, als die "RFC1918"-Regel früher. Prinzipiell sollten sie dasselbe bewirken, aber ganz offensichtlich ist es nicht so... :/

    Ja genau das Problem hatte ich auch gehabt und nicht verstanden.

    Mann hat es nicht leicht, aber leicht hat es einen..

    External Content beta.ubiquiti-networks-forum.de
    Content embedded from external sources will not be displayed without your consent.

    Edited once, last by Naichbindas (April 3, 2025 at 8:51 PM).

    Gut, ich habe die Block-Regel angepasst. Screenshot hier, einmal inklusive dem überschaubaren Regelset für Intern --> Intern:



    Ich kann gerade leider selbst keine Verbindungstests durchführen, werde beobachten. So wirklich logisch erscheint es mir nicht, aber ich will auch nichts unversucht lassen.

    Alles gut. ich sagte ja auch nicht das meine Sache die Lösung ist, sondern sollte als Ansatz dienen, weil es bei mir auch geholfen hatt.

    Ich muss DoPe aber auch Recht geben.

    Und du hast da auch Recht wegen der Logik.

    Aber ich hatte festgestellt, nach der Migration auf die neue ZBF waren viele Regeln von vorher auf einmal um ein vielfaches vorhanden.

    Also einige Regeln waren dann teilweise drei oder viermal vorhanden.

    Diese waren aber auch in Gateway und Intern sowie Extern drinn.

    Da lief das bei mir auch alles noch so wie DoPe beschreibt.

    Aber als ich dann alle Regeln gelöscht hatte und ganz neu mit der ZBF angefangen hatte und dann nur noch wenige Regeln mit der Lösung die ich habe brauchte und ich festellen musste das es nicht mit alles blocken ging daher hatte ich im Internet nach gelesen und Videos geschaut ohne Ende, fand dann diese Lösung.

    Mann hat es nicht leicht, aber leicht hat es einen..

    External Content beta.ubiquiti-networks-forum.de
    Content embedded from external sources will not be displayed without your consent.
    Quote from Networker

    as Du mit "Transfer Traffic" meinst.

    Villeicht doof ausgedrückt.. ich meine das "100.102.8.6" der geht ja nicht ins Internet und auch nicht ins Lokale Netz (gleiche VLAN) oder in LAN (ein anderes VLAN) sondern geht über ein Transfer netz (dein Shared VLAN wo der Konnektor ist) zu einem eignen Router (der Konnektor) der das das durchs VPN schiebt)

    Wenn ich das richtig deute hast du ne Statische Route auf dem Router der diesen dann auf den Konnektor Leitet (korrekt?). Auf dem Cleint macht es ja keinen Sinn. Verkehr geht eh zum Gateway und muss da die richtige Wahl nehmen um zum "Shared VLAN" zu kommen und nicht ins "normale WAN Internet"

    "Konnektor" und SecureNet Konnektor" sind das nur die Loaklen IP von der Konnektor Kiste oder auch die 100.102.x.x Adressen ? Grade der Hinweg könnte von Interesse sein, da ein Paket an ein Fremdes Netz ja die DEST IP as Ziel drinnen hat und mit dieser auch durch die Firewall muss. (Routing 101, DEST IP setzen und im ethernet das Packet an das Interface / L2 MAC schicken die das zuständige Gateway hat)

    Rückrouten kennt der Konnektor ? also weis wie das Client VLAN erreichbar ist ?

    Quote from gierig

    Villeicht doof ausgedrückt.. ich meine das "100.102.8.6" der geht ja nicht ins Internet und auch nicht ins Lokale Netz (gleiche VLAN) oder in LAN (ein anderes VLAN) sondern geht über ein Transfer netz (dein Shared VLAN wo der Konnektor ist) zu einem eignen Router (der Konnektor) der das das durchs VPN schiebt)

    Ok, verstanden. Wobei ja im Prinzip jeglicher Traffic der Praxen durch das Transfernetz geht, da die UDM Pro der zentrale Router mit dem einzigen Internetzugang ist. Anfragen auf 100.102.8.6 usw. werden dann über die statischen Routen an den Konnektor weitergereicht, wobei dieser wiederum auch nur als Client im "Transfernetz" der UDM Pro hängt und über sie ins Internet kommt.


    Quote from gierig

    Wenn ich das richtig deute hast du ne Statische Route auf dem Router der diesen dann auf den Konnektor Leitet (korrekt?).

    Ja, genau. Es funktioniert schon auch, wenn man die statischen Routen auf den Clients setzen würde, aber zentral verwaltet ist das in diesem Fall natürlich schöner und weniger Arbeit. Diese Routen sind auch seit der Ersteinrichtung unverändert.


    Quote from gierig

    "Konnektor" und SecureNet Konnektor" sind das nur die Loaklen IP von der Konnektor Kiste oder auch die 100.102.x.x Adressen ?

    Nur die lokale IPv4-Adresse (10.100.100.60).


    Quote from gierig

    Rückrouten kennt der Konnektor ? also weis wie das Client VLAN erreichbar ist ?

    Ja, das passt alles. Die ganze Telematik funktioniert ansonsten auch, damit gab es nie ein Problem. Das Problem beginnt da, wo eine "Nicht-Telematik-Anwendung", die nicht unmittelbar an den Konnektor gebunden ist, also z.B. ein gewöhnlicher Browser, Ressourcen aufrufen will, die nur über den Konnektor zu erreichen sind. In diesem Moment braucht es die statischen Routen, die ja auch nach wie vor greifen. Nur, dass diese Anfragen dann eben blockiert werden...

    Quote from Networker

    Es funktioniert schon auch, wenn man die statischen Routen auf den Clients setzen würde,

    Wie das ? Ich kann keine Routen legen für mit einem gateway das nicht in meinen Localen netz ist...

    Quote from Networker

    also z.B. ein gewöhnlicher Browser,

    Doffe frage, nen Proxy gibt es nicht der da eingetsellt ist und den Kram erstmal zum Proxy schickt ? (Proxy exeptions als Stichwort)

    Quote from Networker

    Nur die lokale IPv4-Adresse (10.100.100.60).

    Bin mir bei deiner Situation nicht ganz sicher, aber ich wüede denken das die 100.x.x.x ebenso "frei" sein müsse. Weil die stehen im Header von IP Paket drinnen.

    ggf. würde ich mit TCPdump schauen ob die Pakete im Zielnetz ankommen oder obs am rückwerg scheitert um gewissheit zu bekommen.

    Quote from gierig

    Wie das ? Ich kann keine Routen legen für mit einem gateway das nicht in meinen Localen netz ist...

    Stimmt natürlich, ich war da gestern Nacht gedanklich glaube ich irgendwo ganz anders.


    Quote from gierig

    Doffe frage, nen Proxy gibt es nicht der da eingetsellt ist und den Kram erstmal zum Proxy schickt ? (Proxy exeptions als Stichwort)

    Nein, keine Proxys an irgendeiner Stelle.


    Quote from gierig

    Bin mir bei deiner Situation nicht ganz sicher, aber ich wüede denken das die 100.x.x.x ebenso "frei" sein müsse. Weil die stehen im Header von IP Paket drinnen.

    Internet-Adressen blocke ich gar nicht... Also schon, über eine Liste mit Staaten (Geoblocking), aber das hat ja mit diesem Fall nichts zu tun. Die Meldung unter "Triggers" ist da aus meiner Sicht eindeutig und verweist ja auf die Regel "Block: Internal --> Internal". Ist leider im Moment nicht ganz einfach, mal auf eines der dort betroffenen Geräte zu kommen, ansonsten hätte ich schon mal mit TCPdump oder Wireshark geschaut.


    Quote from Naichbindas

    Alles gut. ich sagte ja auch nicht das meine Sache die Lösung ist, sondern sollte als Ansatz dienen, weil es bei mir auch geholfen hatt.

    Erkenntnis von heute: Leider keine Änderung, wenn man die connection states der Regel nur auf "new" und "invalid" schaltet. Probleme bestehen unverändert fort.

Participate now!

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

Register Yourself Login