Contentfilter Work / Family blockt sämtlichen Traffic

Es gibt 22 Antworten in diesem Thema, welches 2.148 mal aufgerufen wurde. Der letzte Beitrag () ist von gierig.

    Hallo zusammen,

    ich habe für meine Kinder ein eigenes VLAN erzeugt, in dem ich nun den Contentfilter "Family" einsetzen möchte. Leider führt das Aktivieren dieser Option dazu, dass kein externer Traffic mehr möglich ist. Leider ist mir nicht klar warum.


    Zu meiner Umgebung:

    • Internetanschluss über Starlink
    • Traffic via NordVPN an einen deutschen Endpunkt (Traffic-Route)
    • GeoIP-Sperre diverser Länder (nicht USA) in beide Richtungen
    • Manuelle Voreinstellung der DNS-Server auf WAN 1 und WAN 2 (9.9.9.9 und 1.1.1.2)
    • Keine manuelle DNS-Voreinstellung im betroffenen VLAN (steht auf Automatik)

    Wenn ich die NordVPN-Verbindung deaktiviere, hat das keinen Einfluss auf die (Nicht-)Funktionalität des Family-Filters.

    Hat von euch jemand eine Idee, woran es liegen könnte, dass die Filtereinstellung zum kompletten Block der Verbindung führt?

    Das hab ich geprüft. Im Firewall-Log stehen keine Blockeinträge.

    Die NordVPN-Thematik hat meines Erachtens keine Auswirkung, da das VPN erst nach dem betreffenden Netzwerk (ab dem WAN-Port) beginnt und vor dem Ziel wieder aufhört. Ich habe das getestet, indem ich das Netzwerk aus dem NordVPN-Routing rausgenommen hab, sodass der Traffic ohne VPN läuft.

    Nach der Aktivierung der Schutzfunktion ergibt sich folgende Situation auf dem Client:

    Just to say.


    Bei den "ContentFiltern" wird dein WAN DNS auf dem Unifi Gateway egal wie er eingestellt ist

    überschrieben mit den jeweiligen DNS IP von https://cleanbrowsing.org/filters/


    was sagt ein "dig google.de @192.168.16.1" bzw. "nslookup google 192.168.1.1".

    Nur um sicherzugehen das dein systemD resolver auch den richtigen Fowarder nutzt.

    den Offensichtlich ist der eingetragen in die /etc/resolv.conf und nicht der Router DNS.

    (weil die Antwort von 127.0.0.53 kommt) sonder der SystemD der

    in evt cat /lib/systemd/resolv.conf oder hier /etc/systemd/resolv.conf

    andere Pläne hat im mit DNS umzugehen...

    Ja, 127.0.0.53 passt schon. Da hört der Dienst drauf.

    Wohin die Anfragen der einzelnen Dienste adressiert werden, kann man mittels

    Code
    resolvectl status

    herausfinden. Das passte bei mir auch (Client -> UDM SE).


    Ich hab nun zahlreiche Versuche mit allen mir zur Verfügung stehenden Optionen gemacht. Letztlich muss ich sagen, dass die DNS-Geschichte in der UDM SE meines Erachtens schlecht oder sogar fehlerhaft umgesetzt ist. Es funktioniert schlichtweg nicht. Normalerweise ist zu erwarten, dass eine Kaskadierung/Priorisierung erfolgt:

    1. DNS lt. DNS-Shield
    2. Contentfilter lt. Netzwerk
    3. DNS lt. Netzwerk
    4. DNS lt. WAN

    Contentfilter lt. Netzwerk funktioniert bei mir nicht. Ich habe eine UDM SE mit aktuellem OS bzw. aktueller Firmware und habe keine manuellen Veränderungen über das CLI (ssh) vorgenommen.


    Tatsächlich scheint das DNS lt. Netzwerk überhaupt keine Auswirkung zu haben. Ich habe dort testweise Cloudflare 1.1.1.3 eingestellt - das dürfte normalerweise den gewünschten Effekt mit sich bringen. Hat es aber auch nicht.


    DNS am WAN war ebenfalls wirkungslos, wie es scheint - auch dort hatte ich 1.1.1.3 mal eingestellt.


    DNS-Shield hat bei mir zumindest dann funktioniert, wenn ich Cloudflare Family als predefined DNS hinterlegt habe.


    Irgendwas passt hier aktuell offenbar nicht. Ich habe aber nach zahlreichen Stunden mit dem Thema aktuell auch nicht wirklich die Zeit mich permanent mit dem Thema zu befassen. Ich habe auf Systemebene Cloudflare 1.1.1.2 und auf Netzwerkebene jetzt mal 1.1.1.3 hinterlegt. Ich hoffe, dass es nach einiger Zeit mal funktioniert, wie es zu erwarten ist.

    Zitat von phino

    Wie das System auf diese gekommen ist, schein einunlösbare Geheimnis.

    Nö, 127.0.0.0/8 ist als Localhost, fertig. Da dürfen auch Dienste sich ne IP aussuchen. im dem fall halt der

    systemD resolver der als "mini DNS" auf die IP hört und im auch nichts anderes macht als zur ip weiterleiten die

    da in der Config steht...



    Zitat von mm2024

    DNS am WAN war ebenfalls wirkungslos, wie es scheint - auch dort hatte ich 1.1.1.3 mal eingestellt.

    Wir wenn Contentfilter an ist eh Überschrieben mit den DNS Anbieter den ich oben erwähnte.

    Fungiert bei mir wenn ich nutzen würde (getestet mit XXX Seiten). Eigentlich müsste man auf der UDM

    dann nun einen TRACE laufen lassen und schauen was da DNS mäßig bei dir pasiert oder woran es hapert.

    Hast du ggf. mal Geoblock ausgeschaltet ? Oder andere Reglen in der Firewall die Einfluss auf DNS machen würden ?

    Ja, tatsächlich hab ich so einiges ausprobiert. Geoblocking hab ich deaktiviert, Adblocking auch mal (beides zusammen deaktiviert).

    Wenn es mir mal zeitlich passt, melde ich mich mal via ssh auf der UDM an und schau mal, oder kann man das auch ber die Weboberfläche mitverfolgen bzw. nachvollziehen (ich vermute nicht...)?

    Zitat von gierig

    Nö, 127.0.0.0/8 ist als Localhost, fertig. Da dürfen auch Dienste sich ne IP aussuchen. im dem fall halt der

    systemD resolver der als "mini DNS" auf die IP hört und im auch nichts anderes macht als zur ip weiterleiten die

    da in der Config steht...

    Natürlich ist der Rang Local. :winking_face:

    Ich frage mich aber, warum der miniDNS 127.0.0.53 wählt, wenn die anderen Dienste nichts davon zu wissen scheinen. Andere Dienste würde ja vermutlich als Standard 127.0.01:53 Fragen zu DNS. Wenn man dies ändert, muss man dies allen auf dem System mitteilen. Daher die Frage wer hat veranlasst, dass der miniDNS ein virtuelle NIC mit 127.0.0.53:53 nutzt/anlegt.

    Bei mir fragt die UDM jedenfalls 127.0.0.1:53, egal ob mit oder ohne Inhaltsfilter, habe aber kein VPN aktiv.
    Fragt sich was genau passiert bei VPN, wird da vielleicht ein virtuelle NIC angelegt, also 127.0.0.53 für die Daten und natürlich mit Port 53 für DNS, nur wenn man die Inhaltsfilterung einschaltet, bekommt sie es nicht mit. Was auf ein Programmier-Fehler hinausläuft.

    Bei mir:

    Code
    root@TOPofRILKE:~# nslookup google.com
Server:         127.0.0.1
Address:        127.0.0.1#53


Non-authoritative answer:
Name:   google.com
Address: 142.251.209.142
Name:   google.com
Address: 2a00:1450:4005:80b::200e
    Zitat von phino

    ndere Dienste würde ja vermutlich als Standard 127.0.01:53 Fragen zu DNS

    Nö... sie werde das verwenden was in /etc/resolv.conf steht. Steht da dann 127.0.0.53 drinnen

    wir der halt benutzt. systemd-resolved benutzt herdcodiert die 127.0.0.53 an der er sich bindet.

    Den rest macht systemd-resolved der dann die fallback DNS server benutzt oder DNS von NetzwerkManager bekommt oder oder oder.


    Sollte eine Distro das nicht machen geht die da ihren eignen anderen weg.

    Was in die /etc/resolv.conf kommt haben vor SystemD schließlich andere Tools

    genauso Dynamisch gemacht (resolveconf, networkmanager ohne systemd, etc.)


    UDM selber hat je nach Config teilweise eine eigne DNS Instanz laufen für jedes VLAN

    (basiert ein wenig auf AD Blocker / Contenfilter/VPN) Die wollen (wie die meisten server)

    auch keine AutoConfig über SystemD :smiling_face:

  • razor

    Hat das Label von keine Lösung auf offen geändert.

    Mir ist heute nacht noch eine Sache in denn Sinn gekommen. Du sagtest ja das DNS

    so garnicht mehr geht wenn du den Contentfilter an hast.


    was ist wenn dein Provider also Starlink da aktuell doof ist?

    Kannst du sich mal auf die Konsole einloggen (ssh)


    Code
    root@Lisa:~# dig +short heise.de @185.228.168.168
193.99.144.80
root@Lisa:~# dig +short reddit.com @185.228.168.168
root@Lisa:~#

    das ist einmal Heise und einmal Reddit über den Family Filter DNS.

    Erwartet wird ne IP für HEISE und halt keine für Reddit. (kannst das +short auch weglassen für mehr Details)


    Sollte der DNS garnicht erreichbar sein, gibt es einen Timeout..

    Code
    root@Lisa:~# dig +short heise.de @185.228.168.168
root@Lisa:~#;; connection timed out; no servers could be reached
    Zitat von gierig

    UDM selber hat je nach Config teilweise eine eigne DNS Instanz laufen für jedes VLAN

    (basiert ein wenig auf AD Blocker / Contenfilter/VPN) Die wollen (wie die meisten server)

    auch keine AutoConfig über SystemD

    Genau in diese Richtung gingen meine Überlegung.
    Bei irgendeiner Funktion (AD Blocker / Contenfilter / VPN) der UDM wird die Netzwerkschnittstelle 127.0.0.53 definiert, aber die anderen Dienste scheinen es nicht zu verstehen./mitzubekommen. Ich glaube, es scheint irgendein Unifi-eigener Script schief zu stehen.

    Zitat von gierig

    Nicht verwechseln, die 127.0.0.53 war auf seinem Client nicht auf der UDM.

    Die macht wie gesagt völlig ihr eignes Ding über klassische Wege. (na ja gesteuert von UNIFI)

    und pfeift auf SystemD oder oldscool Resolver packet...

    Ups, da habe ich dann wohl etwas überlesen und die UDM als Problem gesehen. Wobei, ganz raus ist sie natürlich nicht.

    Dann müsste ja das Problem auf dem Client sich aus irgendwelchen falschen/unvollständigen DHCP Informationen von der UDM basierten. Wie kommt sonst der Client darauf, so etwas zu machen, wenn der TE etwas an der UDM verstellt? Und dass er DHCP einsetzt, ist ja wahrscheinlich, damit die richtigen Filter bei den Kids ankommen.

    Zitat von phino

    Wie kommt sonst der Client darauf, so etwas zu machen, wenn der TE etwas an der UDM verstellt?

    Na weil wenn du ein DIG / NSLOOKLUP / PING sonstwas machts das Linux System

    in der /etc/resolve.conf nachschaut wer der DNS Server ist. Auf SystemD-Resolver systemen

    ist da nunmal der eigne. Der Wiederrum bekommt seine Forwarder dann von der Config als fallbar oder vom NetzwerkManager oder anderen Kram der auf "DESKTOP" installation so vertreten ist.

    Schau in Beitrag 8 da bestätigt er es ist das die UMD schon richtig auf den Client eingetragen ist.


    Sprich die anfrage geht wohl rausfuhr UDM (bin mir zu 99% sicher) aber dann wohl nicht

    weiter..Daher meine letze Idee auf der UDM selber direkt den DNS abzufragen der

    da benutzt wird weil ich mir vorstellen kann das der von Sterling evt nicht erreichbar ist

    (warum auch immer)

    Ich hab euch hier mal ein Netzwerkschema aufgezeichnet:


    Starlink bekommt vom Datenverkehr nichts mit.

    NordVPN geht durch bis zu einem Endpunkt in Deutschland.

    Das funktioniert soweit aus allen internen Netzen.


    Sobald der Contentfilter im VLAN-Netzwerk aktiv ist, ist es nicht mehr möglich aus diesem Netwerk heraus DNS-Auflösungen durchzuführen. Sämtliche Seiten sind nicht mehr erreichbar.

    2 Mal editiert, zuletzt von mm2024 () aus folgendem Grund: Anpassung DNS-Adresse im Schaubild (keine Auswirkung auf Sachverhalt)

    Also das Verhalten bestätigt doch, das die UDM ein Problem mit VPN und Umleitung von internen Datenverkehr hat, hier DNS Anfragen. In diesen Fall scheint der Script von Contendfilter nicht zu raffen, dass es VPN gibt und er die Anfragen für DNS darüber zu senden hat.

    Andere in der Community berichten ja auch darüber das einige Dinge (site-by-site) mit VPN nicht funktionieren. In anderen network-Versionen ging es wieder.

    Ich würde ein Ticket aufmachen.