Beiträge von thebogeyman

Zitat von swag

Nur eine mögliche Variante aber falls Du ein Gerät mit dieser ip im Netz hast könnte die Adresse per multicast DNS an Deinen LG bekannt gemacht werden (auch wenn er sie gar nicht erreichen kann) ZeroConfig sei Dank

Die eine Adresse (192.168.20.1), die ständig gepingt wird, ist ja das Gateway vom entsprechenden VLAN und die andere Adresse (192.168.1.82) gibt es nicht ... nicht einmal das Subnetz dazu

Puh, das war jetzt kompliziert (für mich zumindest), aber ich hab mal einen Dump, den ich in Wireshark ansehen kann.

Leider kenn ich mich damit überhaupt nicht aus. Es fallen mir aber zumindest mal folgende Einträge ins Auge (solche ähnlichen gibts noch mehrere):

Kannst du damit schon was anfangen oder würdest du eher die ganzen Paket-Details benötigen?

Ich würde ja am liebsten den kompletten Dump posten bzw. dir schicken, allerdings ist mir das relativ unsicher, weil ich nicht weiß, was da alles drinnen steht und nicht für die Öffentlichkeit bestimmt ist.

Nächstes Update!

Ich hab jetzt das Nvidia Shield in mein IoT Netzwerk gehängt und ich weiß jetzt auch, warum ich es damals ins Trusted getan habe: Der Zugriff aufs NAS im Trusted ist ... sehr eigenartig. Das NAS wird als Netzwerkspeicher im Shield nicht gefunden, weil es in einem anderen Subnetz ist und ein manuelles hinzufügen funktioniert zwar, jedoch ist der Speicher nach einem Neustart wieder weg und ich muss es händisch neu verbinden.

Aber egal, ich lasse das jetzt erst mal so bis es mir zu blöd wird.

Damit können mein Google Nest und der TV mit dem Nvidia Shield kommunizieren. Ich habe zwar keinen Plan, was die miteinander reden, aber stört mich jetzt auch nicht sonderlich, somit sind diese Meldungen mal weg.

Übrig bleiben damit nur mehr 2 Meldungen:

TV was blocked from accessing 192.168.1.82 by firewall rule: Block inter-VLAN routing
TV was blocked from accessing 192.168.20.1 by firewall rule: Block IoT to UDM interface

Beim ersten sind wir uns einig: Keine Ahnung, warum der TV auf diese IP zugreifen will, obwohl es das Gerät nicht gibt.

Aber der zweite erschließt sich mir auch nicht ganz: Warum will der TV auf die Gateway IP auf Port 80? Kein anderes Gerät will das! Und genau das will ich ja verhindern: Ein IoT Gerät soll nicht auf die Website des Gateways (was übrigens mein Router Interface ist) kommen.

Kanns sein, dass der TV tatsächlich dubiose Sachen versucht? Ich muss dazu sagen, dass der gerootet und webOS Homebrew installiert ist.

So, ich hab das jetzt mit den Logs hinbekommen. Man muss das Logging explizit bei den entsprechenden Regeln aktivieren, damit sie ins Syslog kommen:

Zunächst mal zum "Block IoT to UDM interface":

Source ist immer mein Fernseher, jedoch jedes zweite Mal ein anderer 5-stelliger Port (58494, 58498, 58592).

Ziel ist das IoT Interface 192.168.20.1 auf Port 80

Beim "Block inter-VLAN routing" siehts so aus:

Source sind meistens mein Fernseher oder noch häufiger mein Google Nest Hub, wieder jedes zweite Mal ein anderer 5-stelliger Port.

Ziel sind mein Nvidia Shield (welches im Trusted Network läuft) auf Port 9000 und diverse IP-Adressen im 192.168.1.x und 192.168.0.x Subnetz auf Port 80 (wobei ich nicht einmal ein 192.168.1.x bzw. 192.168.0.x Subnetz habe!?).

Keine Ahnung was die kommunizieren wollen.

Ich versuche mal rauszufinden, was Port 9000 auf dem Nvidia Shield ist.

Außerdem frage ich mich gerade, warum ich das Nvidia Shield überhaupt ins Trusted Network habe und nicht ins IoT, aber ich denke, ich konnte damals auf mein NAS (im Trusted) nicht zugreifen. Vielleicht sollte ich das wieder ändern und eine entsprechende Firewall Regel anlegen.

Zitat von jkasten

Da Adguard nicht der DHCP ist, kann er die Namen nicht auflösen. Entweder die Clients alle im Adguard anlegen oder den Adguard auch als DHCP nutzen.

Aber ist nicht eigentlich genau für diesen Fall die Einstellung "Private inverse DNS-Server" da? Wenn dort die Adresse der UDM eingetragen ist und diese die Hostnamen kennt, sollte Adguard diese dann doch auch kennen und auflösen können, oder verstehe ich hier was falsch? Hab leider auch erst angefangen, mich mit diesem Thema zu beschäftigen, daher versteh ich einiges noch nicht so ganz.

Dort sind zwar viele Meldungen, aber keine passende. Muss ich wohl weitersuchen ...

Meine var/log/ulog/syslogemu.log ist leer. Wie bekomm ich denn die Triggers-Logs da rein?

Ok, danke, ich werde das mal verfolgen und bei Gelegenheit versuchen, mitzuloggen.

Außerdem würde mich selbst auch interessieren, ob das nur bei Verwendung der Sky Q App auftritt, oder generell wenn der Fernseher läuft.

Kann ich leider erst am Abend prüfen.

Zitat von thebogeyman

Ok, danke, ich werde das mal verfolgen und bei Gelegenheit versuchen, mitzuloggen.

Außerdem würde mich selbst auch interessieren, ob das nur bei Verwendung der Sky Q App auftritt, oder generell wenn der Fernseher läuft.

Kann ich leider erst am Abend prüfen.

LIegt nicht nur an Sky Q. Habe gestern die Meldungen auch ohne die App bekommen und habe dann versucht, alles mögliche, was potentiell nach außen kommunizieren könnte, am Fernseher abzudrehen (ein IOT Gerät war tatsächlich im Dashboard eingetragen). Hat aber nichts gebracht.

Ok, danke schon mal für die Hilfe und Erklärung!

Das "Drop invalid state" hab ich jetzt mal rausgenommen.

Bliebe für mich nur mehr die Frage, warum mein Fernseher so oft das Gateway ansteuern will und was es mit der 192.168.1.82 auf sich hat.

Was mir aber gerade aufgefallen ist: Die "Block IoT to UDM interface" Regel sollte ja nur für die Ports 80, 443 und 22 gelten, da ich nicht will, dass ein Gerät innerhalb des Netzwerkes auf das Router-Interface kommt. Im Log stehen bei den Port-Infos unterschiedliche 5-stellige Nummern, die mit 3 beginnen (36604, 36696, 36804, ...). Sollte das überhaupt geblockt werden?

Und warum macht das nur der Fernseher und keine anderes Gerät im IoT Netzwerk?

BTW, ich habe mich beim Einrichten der Firewall-Regeln an diesem Guide orientiert, wo alle meine Regeln dabei sind (auch das "Drop invalid state"): https://lazyadmin.nl/home-network/unifi-vlan-configuration

Die Erklärung zu der "Drop invalid state" Regel vom Autor ist folgende:

Zitat

The firewall not only blocks strange or messed-up packets but also rejects any packets that don’t belong to an ongoing conversation. Think of it like this: if you were getting a file, and the transfer finished, the connection would close. So, if the server sends more data after that, the firewall sees it as odd because there’s no active talk going on. To be safe, it’s smart to have these rules to stop any weird attempts from a compromised device.

Zitat von gierig

Würde (für mich eh unsinnig weilLAN) regeln rauswerfen oder zumindestens Stumm Schalten.

Nur die "Drop invalid state" oder andere auch?

Zitat

Hattest du vorher mal 192.168.1.9/xx beim TV im Einsatz ? Ich denk da so an Remote, Soundbars, Streaming boxe,

DNLA server von anderen Rechnern / NAs Boxen. Villeicht aber auch irgendeine default IP von LG bei der eine Config gezogen werden kann

(für Hotel Mode, Whitebord, etc)

Ich hatte eigentlich nie ein 192.168.1.x Subnetz. Mein Default (trusted) ist 192.168.86.0/24.

Vielleicht hilft die Information, dass während dieser Log-Einträge die Sky Q-App auf dem Fernseher lief.

Übersicht

Allow Established and Related

Drop invalid state

Block inter-VLAN routing

Block IoT to gateways

Block IoT to UDM interface

Profile

Hallo,

ich habe eine UDM (UniFi OS 3.1.16, Network 8.0.7) mit 4 VLANs und entsprechende Firewall-Regeln.

Die wichtigsten davon für mein "Problem" sind folgende:

Wenn ich mir unter System Log -> Triggers die Einträge ansehe, kommen dort minütlich welche dazu.

Mein Raspberry Pi, die Google Nest Geräte und mein Wall Tablet (Amazon Fire) treffen ganze Zeit die zweite Firewall-Regel:

Zudem ist mir aufgefallen, dass mein LG Fernseher regelmäßig versucht, auf das VLAN Gateway und die IP-Adresse 192.168.1.82 zuzugreifen. Ich habe allerdings kein Subnetz 192.168.1.x deklariert.

Sind diese Einträge "normal" und haben die irgendwelche Auswirkungen auf Performance/Geschwindigkeit?

Danke!