@jhf2442: Evtl. kann @Grinch weiterhelfen. Rein interessehalber: Wozu der Aufwand, den MR hinter einer zusätzlichen Firewall zu betreiben, vor allem, wenn der eher gefährdete PC direkt am Speedport hängt?

 

Gruß Ulrich

Oje.. das kann ehrlichgesagt so ziemlich alles sein. Also ja, nach 5 Sekunden Standbild ist so der Klassiker für Multicast kommt nicht durch. Also wahrscheinlich ein Thema des igmpproxy/mcproxy oder der Firewall oder beides.
Letztlich ist da logs wühlen angesagt und mit tcpdump die Blackbox Linux Router von beiden Seiten betrachten. D.h. tcpdump auf der Seite, wo der MR dran hängt und parallel auf der Seite wo es zum Speedport geht.
Erstmal reichts auf "igmp" zu filtern, da solltest du auf beiden Seiten mehr oder weniger die gleichen Pakete sehen. Wahrscheinlich siehst du aber nur vom MR den IGMP Request und der Linux Router schickt ihn nicht an den Speedport weiter. Dann gilts sich mal das igmpproxy log anzuschauen. Da solltest du zumindest mal den Request des MR sehen. Wenn nicht, Firewall prüfen. Wenn ja, dann sollte der igmpproxy das auf sein upstream weiterleiten - wenn nicht, igmpproxy config prüfen (üblicherweise gibt das log Aufschluss was in der config noch fehlt). Wenn auch das funktioniert wieder firewall prüfen, ob der ausgehende Request geblockt wird. Ist auch das nicht der Fall, müsste der Multicast immerhin bis zum Linux Router kommen und dann gilts wieder zu gucken wo er hängen bleibt, also wieder Firewall.
Im Zweifel kann es auch Sinn machen von der Firewall verworfene Pakete zu loggen, vielleicht macht das schlauer.

Also kurz: da wirst du dich durch den ganzen Matsch wühlen müssen um Multicasat mit IGMPv3 und SSM zu routen, ein pauschaler Tipp woran es liegt hab ich leider nicht. Mag schon sein, dass es nur ein Detail ist, nur das ist die Nadel im Heuhaufen