Hallo,
versuche aus 2 Netzen (eth1(192.168.1.x) und eth2(192.168.2.x))
auf einen DLNA Server (192.168.1.160) an eth1 zuzugreifen.
Habe folgende Regel angelegt:
DLNA Server -> Netzwerk an eth2 -> any Accept
Netzwerk an eth2 -> DLNA Server -> any Accept
Dadurch ist nun der Zugriff auf Netzwerkfreigaben auf dem DLNA Server möglich. Ebenso kann ich auf das Web Interface des Servers zugreifen.
Allerdings findet kein DLNA Client in dem Netz an eth2 den DLNA Server.
Aus Netz an eth1 funktiniert der Zugriff einwandfrei.
Wo könnte das Problem liegen?
DLNA/Medienserver Zugriff von 2 Interfaces
Moderator: Securepoint
Nun ja, normalerweise ist es so, das sobald der Dlna Clíent eingeschaltet wird automatisch nach DLNA Server gesucht wird und alle DLNA Server am Client angezeigt werden. Danach kann dann aml Client gewählt werden ob audio, video oder foto wiedergeben werden soll.
Bei meinem Problem is es nun so das wenn ich den DLNA Client in dem Netz an eth2 anschließe keine DLNA Server angezeigt werden.
Schließe ich den Client in dem Netz an eth1 an wird der DLNA Server angezeigt und kann benutzt werden.
Bei meinem Problem is es nun so das wenn ich den DLNA Client in dem Netz an eth2 anschließe keine DLNA Server angezeigt werden.
Schließe ich den Client in dem Netz an eth1 an wird der DLNA Server angezeigt und kann benutzt werden.
Moin,
dann vermute ich mal das die "Suche" anhand von Broadcast oder Multicast passiert und beides ist nicht ohne weiteres Routingfähig.
Schon mal das Log kontrolliert was es so an "DROP" einträgen gibt?
dann vermute ich mal das die "Suche" anhand von Broadcast oder Multicast passiert und beides ist nicht ohne weiteres Routingfähig.
Schon mal das Log kontrolliert was es so an "DROP" einträgen gibt?
There are 10 types of people in the world... those who understand binary and those who don\'t.
Hallo,
folgender DROP wird jeweils in dem Moment ausgeführt in dem ich den Client starte
folgender DROP wird jeweils in dem Moment ausgeführt in dem ich den Client starte
Code: Alles auswählen
<4>Nov 27 14:15:32 kernel: DROP(default) IN=eth2 OUT=eth1 MAC=4c:02:89:00:2d:51:00:01:6c:71:ac:4a:08:00 SRC=192.168.1.160 DST=192.168.1.250 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=18101 DF PROTO=TCP SPT=52377 DPT=5003 WINDOW=8192 RES=0x00 SYN URGP=0
<28>Nov 27 14:15:39 named[2681]: client 192.168.1.160#39333: RFC 1918 response from Internet for 1.1.168.192.in-addr.arpa
Irgendwas passt hier nicht zusammen. Das Log sagt, dass die IP 192.168.1.160 hinter eth2 ist, wo lt Ihrer Aussage 192.168.2.0/24 sein soll.
Kann es sein, dass ihr DLNA-Server eine IP in beiden Netzen hat und die beide am gleichen Switch hängen? Wenn ja, antwortet der nämlich mit der falschen IP.
Sie sollten die beiden Netze nicht nur logisch, sondern auch physikalisch trennen.
Kann es sein, dass ihr DLNA-Server eine IP in beiden Netzen hat und die beide am gleichen Switch hängen? Wenn ja, antwortet der nämlich mit der falschen IP.
Sie sollten die beiden Netze nicht nur logisch, sondern auch physikalisch trennen.
HM hab grade nochmal geschaut, da ist mir beim abtippen wohl ein Fehler unterlaufen.
So ist es richtig
So ist es richtig
Code: Alles auswählen
<4>Nov 27 14:15:32 kernel: DROP(default) IN=eth2 OUT=eth1 MAC=4c:02:89:00:2d:51:00:01:6c:71:ac:4a:08:00 SRC=192.168.2.160 DST=192.168.1.250 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=18101 DF PROTO=TCP SPT=52377 DPT=5003 WINDOW=8192 RES=0x00 SYN URGP=0
<28>Nov 27 14:15:39 named[2681]: client 192.168.2.160#39333: RFC 1918 response from Internet for 1.1.168.192.in-addr.arpa
Ich wette 3 Internets, dass die "Suche" des Servers über Broad-/Multicasts erfolgt (wie mein geschätzter Kollege bereits festgestellt hat) und deshalb in der DMZ gespenstische Stille herrscht.
Desweiteren:
Wer ist 192.168.2.160 und wer ist 192.168.1.250? Die beiden versuchen da ja zu kommunizieren...
Desweiteren:
Wer ist 192.168.2.160 und wer ist 192.168.1.250? Die beiden versuchen da ja zu kommunizieren...
192.168.2.160 ist der DLNA Client.
Was sich hinter 192.168.1.250 verbirgt weiß ich nicht, kein Gerät in meinem Netzwerk hat so eine IP Adresse und 192.168.1.250 ist auch nicht anpingbar.
Kann man Broad/Multicast irgendwie so routen das sie in das andere Netz weitergeben werden?
Was sich hinter 192.168.1.250 verbirgt weiß ich nicht, kein Gerät in meinem Netzwerk hat so eine IP Adresse und 192.168.1.250 ist auch nicht anpingbar.
Kann man Broad/Multicast irgendwie so routen das sie in das andere Netz weitergeben werden?
Würde mir persönlich Sorgen machen, wenn mein Client nach irgendwohin ne Verbindung öffnet. Zum Glück ist da ne Firewall, die es blockt...
Um Broad-/Multicasts zu "routen" benötigt man einen speziellen Proxy auf dem jeweiligen Router. Für Multicasts gibt es in der UTMv10 den igmp_proxy. Konfiguriert werden kann der nur über das Template /etc/igmpproxy.conf (Extras -> Erweiterte Einstellungen).
"Upstream" meint in dem Zusammenhang immer das Interface/die IP des Servers, "Downstream" respektive die Client-Seite.
Bewusst funktionieren tut der mit IPTV, keine Ahnung, ob damit auch der Zugriff auf Ihren Server möglich ist. Es konnte ja noch niemand sagen, WIE genau der Zugriff nun erfolgt...
Um Broad-/Multicasts zu "routen" benötigt man einen speziellen Proxy auf dem jeweiligen Router. Für Multicasts gibt es in der UTMv10 den igmp_proxy. Konfiguriert werden kann der nur über das Template /etc/igmpproxy.conf (Extras -> Erweiterte Einstellungen).
"Upstream" meint in dem Zusammenhang immer das Interface/die IP des Servers, "Downstream" respektive die Client-Seite.
Bewusst funktionieren tut der mit IPTV, keine Ahnung, ob damit auch der Zugriff auf Ihren Server möglich ist. Es konnte ja noch niemand sagen, WIE genau der Zugriff nun erfolgt...