DNLA über Netzwerkgrenzen

[Fidibus]

Moin,
nach dem Umbau meines Netzes soweit erledigt ist, habe ich bisher eine Baustelle entdeckt.
Das ist der Netzplan:

Die TV-Geräte und der Denon AVR sollen nun wieder die Inhalte auf dem NAS erreichen können.
Der Weg über eine Netzwerkfreigabe ist im Menü erst einmal so nicht zu finden gewesen.
Nach einigen Hinweisen aus dem Forum ist ein Lösungsansatz erkennbar.
Problem: hier mal beschrieben
Lösungsansatz: hier der Hinweis
@Barungar Zitat:
Sollte auf einer pfSense mit dem Paket UDP Broadcast Relay gehen.
https://docs.netgate.com/pfsense/en/latest/packages/udpbroadcastrelay.html
Ich habe schon einmal das package installiert.
Weiterhin habe ich das Teil konfiguriert:

UDP 15600 habe ich im Log gefunden, damit scheinen die Samsung TV's (Samsung, QE55Q9FNA und GQ49Q70RGTXZG) ins Netz zu brüllen.
Dazu gibt es auf beiden Interfacen Regeln.

Natürlich funktioniert es so noch nicht - und hier gehe ich jetzt in den try and error Modus - und habe Hoffnung, dass ihr Hilfestellung geben werdet.

 

[Barungar]

@Fidibus Du wolltest doch DNLA?!

Laut der verlinkten Anleitung für das Paket (siehe mein Post oben) sind das UDP-Pakete auf Port 1900, die an die Multicast-IP 239.255.255.250 gesandt werden. Die musst Du dann aus dem Netz, in dem den DNLA-Server ist auch in das andere Netz weiterleiten.

 

[Fidibus]

Ich hatte 1900 drin, da ist nichts passiert, ausser

Vorher war die IP 239.255.255.250 mit dem Port (15600) Ziel.
Die Regel zieht ja auch:

An sich ist ja die jetzt geblockte Adresse die BC-Adresse im Netz.
Port 1900 wird aktuell von Homeassistant und den Reolink-Cams angesprochen.

 

[Fidibus]

Ich korrigiere erst einmal ein Fehler: Tausche in der Konfig OPT1 gegen OPT2 -
Update: Ohne Erfolg.

 

[Barungar]

Ich verstehe das oben aber auch nicht... wieso Port 15600?
SSDP ist Port 1900

Ich habe zwar kein DNLA-Device bei mir im Netz. Aber ein SONOS-System...
Also habe ich Wireshark angeworfen und siehe da...

Startet man die SONOS App, so sendet sie ein SSDP-Paket an 239.255.255.250:1900
Und erhält kurz darauf von allen SONOS, die das Multicast erhalten haben, eine Antwort.

Konkret ist es:

• IP des Devices sendet UDP SSDP von zufälligen Port A an Port 1900 von MC-Addr 239.255.255.250
• IP der div. SONOS senden von zufälligem Port X eine UDP SSDP-Antwort an Port A der IP des Devices

Die Suche ist Multicast, die Antworten sind Unicast.

 

[Fidibus]

Ich verstehe das oben aber auch nicht... wieso Port 15600?

Zuerst mal der Inferfacefehler.
Egal welcher Port, hätte so dann nicht funktionieren sollen.
Ins Log geschaut: TV hat diese BC-Adresse mit Ziel 15600 angeschrien.
Und das macht sie immer noch, im Wechsel mit der Netz-BC.

Der Denon sieht da anders aus:

Der findet zwar immer noch keine Inhalte, aber das ist noch eine andere Baustelle.
Nachsatz:
In der Rückrichtung fragt das NAS auch auf 1900:

 

[Barungar]

Ich kann Dir nicht sagen, was udp 15600 sein soll. Das ist zumindest kein "well known service".
udp 1900 zumindest ist SSDP und damit lassen sich "Dienst" auffinden.

Wäre nice, wenn man sich mal diese 15600er Pakete anschauen könnte.
Die udp 1900 von Deinem Denon wird echtes SSDP sein. Und auch Dein NAS macht offenbar sauber SSDP.
Keine Ahnung, was der Samsung TV da proprietäres macht.

Mit einer passenden Weiterleitung von udp 1900 sollten sich zumindest Denon und NAS "finden".

 

[Fidibus]

Die udp 1900 von Deinem Denon wird echtes SSDP sein.

Und trotzdem finde ich das NAS nicht.
Handlingsfehler bei mir?

 

[Fidibus]

Noch einmal ein Logauszug:

TV-Absendeport 58564 fragt zuerst seine Netz BC, dann erscheint das Paket 2 mal an OPT2 mit Ziel dortige Netz BC. Ist das so richtig?
Ein Vergleich mit dem Denon:

Der fragt zumindest immer die Multicast-Adresse.
Muss ggf. in der pfsense noch etwas konfiguriert werden?

 

[Barungar]

Ich würde das mit Wireshark mitscheiden, dann würde man viel mehr sehen und wissen.

 

[blurrrr]

https://eu.community.samsung.com/t5...ing-udp-packets-on-port-15600-to/td-p/5794185 scheint so, als könne man das vernachlässigen

 

[Fidibus]

Der TV nutzt nur 15600, kein 1900.
Da es zusammen in einem Netz funktioniert, sollte es doch eigentlich auch hinzubekommen sein?
Ich habe im NAS noch einmal die Geräteliste im DNLA-Server geputzt.
Außer der eigenen Adresse wird nichts weiter erkannt, auch der Denon nicht.
Daher werde ich das Gefühl nicht los, irgendwo noch etwas vergessen zu haben.
Doch...er fragt doch auch regelkonform:

 

[blurrrr]

Der TV nutzt nur 15600, kein 1900.

Schon komisch irgendwie, da 1900/UDP der Standard ist... DLNA ist aber am TV auch eingeschaltet? Eventuell mal ausmachen und wieder einschalten (Reboot tut gut, heisst es ja auch öfter mal ).

Ansonsten... Könntest mal eine "Floating Rule" erstellen, welche für TV/Syno gilt (Direction: Any, Protokoll: Any -> Allow), die nach ganz oben in der Liste schieben (falls es nicht eh schon die erste ist) und das Logging einschalten. Dann solltest Du alle Pakete sehen, welche zwischen den beiden Geräten hin und her wandern. Die "normale" LAN-Regel würde ich dafür nicht zwecks Logging nutzen, da dürfte zuviel von anderen Gerätschaften auftauchen.

Alternativ - so wie schon von @Barungar vorgeschlagen - Traffic mitschneiden (Diagnostics / Packet Capture) und mittels z.B. Wireshark anschauen, da sieht man dann wesentlich mehr

 

[Fidibus]

Schon komisch irgendwie, da 1900/UDP der Standard ist... DLNA ist aber am TV auch eingeschaltet?

Doch...er fragt doch auch regelkonform:

Ich musste mich korrigieren, er fragt - aber nicht so oft.
Das andere schaue ich mir mal an.
Wireshark ist auch noch ne Option.
Danke euch.

 

[Fidibus]

eine "Floating Rule" erstellen, welche für TV/Syno gilt (Direction: Any, Protokoll: Any -> Allow)

Keine neuen Erkenntnisse:

 

[blurrrr]

Ich hatte eigentlich nicht ohne Grund geschrieben, dass die Sachen alle auf "any" stehen sollten, also Protokoll "any" und Destination ebenfalls "any". In Deinem Fall bedeutet das: Floating Regel erstellen, im Dialog dann "Interface" auf "LAN+OPT2" (wenn OPT2 das NAS-Netz-Interface ist), Protokoll "any", aber ist eigentlich auch egal...

Mach einfach einen Paketmitschnitt, zeichne einfach alles von den beiden Interfaces auf und dann wird man schon sehen. In besagtem Zeitraum kannst Du dann ja mal Dein TV bemühen, dass er sich mal im Netz umschauen soll, ggf. wird was gefunden und dann ruhig mal den Zugriff versuchen (also - sofern möglich - auch konkret mal einen Fehler provozieren)

 

[Fidibus]

Die Regel hab ich angepasst, ich habe "Floating rule" nicht verstanden, muss da erst noch einmal nachlesen.

Mach einfach einen Paketmitschnitt

Wie am Besten?

 

[the other]

Moinsen,
das macht die pfsense für dich:
Diagnostics > Packet Capture > IF wählen...
Das dann mit wireshark auswerten.

 

[Fidibus]

Ich habe etwas mitgeschnitten, ich melde mich morgen....mit den Fragen.

 

[the other]

Moinsen,
yup.
Mal so von der Seitenlinie schlau reingeschwätzt: meinst du nicht, es wäre einfacher, das NAS zu den Medienclients ins Netzwerk zu stecken? Ich mein nur, das verursacht weniger Traffic, der über die Firewall geht. Außerdem ist dein historisch gewachsener Netzaufbau ja eh recht durcheinander, wie du ja in vorherigen Posts auch erklärt hast. Daher die ketzerische Frage: lohnt der Aufwand bzgl DLNA über Netzsegmente?
Aktuell werkeln in deinem LAN ja ebenfalls alle möglich Spielarten gemeinsam: vom TV und AVR über smart home...in welchem Segment sind dein PC, die wireless Clients der Familie eigentlich? Wenn auch die im LAN sind, dann würde ich an dieser Stelle eher nochmal diese Einteilungen überdenken...oder eben so lassen, dann kann das NAS aber IMHO auch ins LAN Segment, das dann mit der synology-eigenen Firewall absichern. Problem gelöst.

Ich selber hab es wie an anderer Stelle schon gesagt einfach gelöst: Medienserver ist im selben Segment. Die Streamingclients dürfen gemäß Firewall auf dem NAS genau das: DLNA, alles andere wird von der Seite kommend geblockt.
EDIT: die mobilen Geräte (Smartphones und Tablets) sind im eigenen Segment, die greifen aber auch nicht via DLNA auf Medien zu, sondern per smb...Und sind ebenfalls per pfsense und Synology Firewall im Zugriff begrenzt, haben ihre eigenen Anmeldedaten und Konten auf dem (anderen) NAS und damit auch eingeschränkte Rechte auf Anwendungen, Ordner und Dateien.