[HowTo] MagentaTV mit pfSense 2.4.5

[arnog]

Hallo zusammen,

wegen MagentaTV bin ich vor einiger Zeit von pfSense zu einem Ubiquiti ER-X gewechselt. Nachdem das igmpproxy-Paket in pfSense aktualisiert wurde, habe ich einen neuen Versuch unternommen, MagentaTV mit pfSense ans Laufen zu bekommen. Und wie auch andere schon geschrieben haben: es geht!

Da ich ein paar Beiträge gesehen habe, wo Probleme mit der Konfiguration aufgetreten sind, möchte ich meine Konfiguration hier exemplarisch erläutern und auch ein paar Hinweise zur Fehlersuche geben. Die Profis verzeihen mir bitte die ein oder andere Unschärfe und Vereinfachung. :-)

MagentaTV - Multicast und Unicast

Zunächst einmal ist es für die Fehlersuche hilfreich zu verstehen, wie die Media Receiver für MagentaTV funktionieren und was es mit Unicast und Multicast in diesem Zusammenhang auf sich hat. Auf die Feinheiten von Unicast und Multicast möchte ich hier nicht detailliert eingehen, nur so viel: bei Unicast wird ein Paket von einem Sender zu einem Empfänger geschickt. Bei Multicast wird ein Paket von einem Sender an einen oder mehrere Empfänger geschickt. Technisch wird das realisiert, indem ein Empfänger einer so genannten Multicast-Gruppe beitritt und so sein Interesse bekundet, die Pakete zu empfangen, die an diese Gruppe geschickt werden. Der Sender sendet dabei ein Paket also nicht mehrfach an einzelne Hosts, sondern sendet das Paket an die Adresse der Mutlicast-Gruppe. Die aktiven Netzwerkkomponenten kümmern sich dann darum, dass die Pakete "vervielfältigt" werden und an die interessierten Empfänger geschickt werden. Für Multicast-Gruppen sind Adressen im Bereich 224.0.0.0/4, sprich 224.0.0.1 bis 239.255.255.254 vorgesehen, wobei nicht alle frei verwendet werden dürfen, da es einige Adressen gibt, die für spezielle Zwecke reserviert sind.

Für das Ausspielen von IPTV hat Multicast den Vorteil, dass die benötigte Bandbreite reduziert wird. Wenn zum Beispiel 1000 Haushalte ARD schauen und die Übertragung per Unicast realisiert wäre, müsste der Server jedes Paket 1000 mal senden - an jeden Haushalt eins. Neben der benötigten Bandbreite erzeugt das auch höhere Last auf Serverseite - das skaliert also nicht gut. Bei Multicast sendet der Server das Paket nur einmal und die Pakete werden nur an den Stellen durch die aktiven Netzkomponenten "vervielfältigt", wo es nötig ist.

Allerdings hat Multicast auch Nachteile, weswegen wir uns überhaupt mit dem IGMP-Proxy und Paketfilterregeln beschäftigen müssen. Der eine Nachteil besteht darin, dass Multicast-Traffic standardmäßig nicht geroutet wird, das bedeutet, Multicast-Pakete werden vom Router in der Regel verworfen. Hier springt der IGMP-Proxy ein. Der zweite Nachteil liegt darin, dass es bei Multicast nach dem Beitreten zu einer Gruppe länger dauert als bei Unicast, bis das erste Paket empfangen werden kann. Deswegen fordern die Media Receiver der Telekom beim Umschalten auf einen anderen Sender den Stream zunächst per Unicast an und schalten erst nach ein paar Sekunden im Hintergrund auf Multicast um. Das ist der Grund, weswegen man ohne irgendeine besondere Konfiguration an der pfSense beim Umschalten immer ein paar Sekunden den Sender sehen kann und es danach anfängt zu ruckeln und irgendwann der Stream ganz stoppt.

Eine weitere Besonderheit von Multicast ist, dass zwischendurch geprüft wird, ob ein Empfänger überhaupt noch online ist. Falls nicht, wird der Empfänger aus dieser Gruppe entfernt und es wird auch nicht versucht, weiter Pakete an ihn zu senden.

Um nun erfolgreich Multicast-Pakete empfangen zu können, kommen zwei verschiedene Protokoll zum Einsatz: IGMP und UDP. IGMP-Pakete dienen zur Verwaltung der Multicast-Gruppen. D.h. wenn ein Empfänger einer Gruppe beitreten möchte, schickt er ein bestimmtes IGMP-Paket. Wenn geprüft werden soll, ob ein Empfänger noch online ist, wird dies auch durch IGMP-Pakete gemacht. Über UDP wird der eigentliche Content, also die Video-/Audio-Daten an die Multicast-Gruppe geschickt.

Zusammengefasst müssen also IGMP-Pakete aus unserem internen Netz zur Telekom und zurück geroutet werden. Und wir müssen UDP-Pakete an die Multicast-Gruppe akzeptieren und routen, die nicht wie andere UDP-Pakete als Antwort auf eine Anfrage aus unserem Netz dienen und deswegen vom Paketfilter eigentlich abgewiesen werden.

Konfiguration

IGMP-Proxy

Die von MagentaTV verwendeten Multicast-Gruppen liegen im Adressbereich 232.0.0.0/16. Da MagentaTV auf IGMPv3 bzw. so genanntes Source Specific Multicast setzt, müssen wir auch noch die Quelle kennen. Die ist in unserem Fall eine einzelne Adresse, nämlich 87.141.215.251. Diese beiden Adressen brauchen wir für den upstream-Teil der Konfiguration des IGMP-Proxys. Für den downstream-Teil benötigen wir das interne Netz, in dem sich der bzw. die Media Receiver befinden. Wenn das interne Netz zum Beispiel das Netz 192.168.1.0 mit Netzmaske 255.255.255.0 ist, sieht die Konfiguration wie folgt aus:

Paketfilter Regeln

IGMP Outbound

Wir müssen dafür sorgen, dass der Media Receiver IGMP-Pakete versenden darf. Wer es sich einfach machen möchte, kann bei der Default allow LAN to any rule unter Advanced Options Allow IP options aktivieren. So erreicht aber der komplette IGMP-Verkehr aus dem lokalen Netz die pfSense und den IGMP-Proxy. Wer es gerne etwas kontrollierter haben möchte, legt eine zusätzliche Regel an, die IGMP-Pakete nur von den Media Receiver erlaubt. Im Beispiel heisst die Regel LAN MagentaTV IGMP. Ich habe einen Alias für die Receiver angelegt und diesen als Source verwendet. Wer nur einen besitzt, kann als Source direkt die IP-Adresse des Media Receivers verwenden. In dieser Regel Allow IP options aktivieren.

ACHTUNG: Die neue Regel muss vor(!) der Default allow LAN to any rule stehen, da sonst die IGMP-Pakete schon verworfen werden, bevor sie überhaupt bei unserer neuen Regel ankommen.

UDP Inbound

Jetzt haben wir erstmal soweit alles konfiguriert, dass der Media Receiver einer Multicast-Gruppe beitreten kann. Trotzdem stockt das Bild noch nach ein paar Sekunden, weil wir den Content per Multicast noch nicht akzeptieren. Hierfür müssen wir auf der WAN-Seite eine Regel anlegen, die UDP-Pakete mit Quelle 87.141.215.251 und Ziel 232.0.0.0/16 akzeptiert. Wenn ihr diese Regel jetzt hinzufügt, müsste schon das Umschalten von UDP auf Multicast funktionieren und ihr solltet einige Zeit ohne Ruckeln ein Bild sehen können. Allow IP options braucht nicht aktiviert zu werden.

IGMP Inbound

Jetzt fehlt noch der letzte Baustein: IGMP-Pakete eingehend zu akzeptieren. Wenn ihr bis hierher gefolgt seid, werdet ihr feststellen, dass trotzdem nach einiger Zeit (ein bis zwei Minuten) der Stream kurzzeitig abbricht, um kurz darauf wieder zu laufen. Das liegt daran, dass die "Sendeseite" zwischenzeitlich per IGMP-Paket prüft, ob der Empfänger überhaupt noch online ist. Da diese Pakete verworfen werden, wird der Empfänger aus der Multicast-Gruppe entfernt, es kommt also kein Content mehr an. Der Media Receiver versucht dann wieder der Gruppe beizutreten und das Spiel beginnt von neuem, bis wieder das IGMP-Paket verworfen wird.

Deswegen fügen wir folgende Regel auf der WAN-Seite hinzu. Bitte hier aber die Allow IP options aktivieren!

Zusammen sieht das WAN-seitig dann so aus:

Jetzt solltet ihr unterbrechungsfrei MagentaTV über pfSense schauen können.

Setup

Als Referenz hier mein Setup: Telekom VDSL 100 -> DrayTek Vigor 130 (reiner Modembetrieb) -> APU.1D4 mit pfSense (macht PPPoE und VLAN 7-Tagging) -> Cisco SG350 -> TP-Link T1500G-8T

Ein MR 401 hängt am T1500G-8T, ein MR 201 hängt direkt am SG350. Beide Switches unterstützen IGMPv3 Snooping.

Ich hoffe, das hilft dem ein oder anderen. :-)

Freue mich über Feedback!

[ProNet36]

@arnog

Ich habe es bei mir genau eingerichtet und es läuft fast perfekt.
Aber ich habe ab und zu freezer.
Manchmal 1 am Abend, aber manchmal auch mehrere pro Stunde.
Die Sender sind eigentlich egal.

Ganz schlimm wird es wenn ich einen Download am PC starte. dann hackt und stottert es komplett.

Gibt es die Möglichkeit eine Bandbreite für IGMP zu reservieren, so dass diese absoluten Vorrang vor allen anderen hat?

Viele Grüße

ProNet

[arnog]

@pronet36

IGMP ist nur das Steuerprotokoll, über das der Receiver mitteilt, dass er einer Multicast-Gruppe beitreten möchte bzw. dass er an den Pakten interessiert ist. Diese Nachrichten sind im Vergleich zum Content relativ klein und tauchen bei weitem nicht so oft auf, wie der eigentliche Content. Insofern vermute ich, dass die Priorisierung von IGMP Dir nicht helfen wird. Bei Dir scheint der eigentliche Multicast Content Probleme zu machen.

Aus der Ferne ist es gerade etwas schwierig, Dir hier zu helfen, ohne etwas mehr über Dein Setup zu wissen (verwendete Switches, Access Points, wie sind die Receiver angebunden usw.). Kannst du das mal aufschreiben und vielleicht ein Bild posten?

[ProNet36]

@arnog

Hi,

vielen dank für die Antwort!
Meine Konfiguration sieht folgendermaßen aus:

Draytek Vigor 165 (als reines Modem)---pfsense---Switch (netgear GS108Ev3) und an diesem Switch hängen die 2 Mediareceiver.

IGMPv3 snooping ist im Switch aktiviert und mit der alten Konfiguration (Fritzbox als Router) lief das ganze absolut fehlerfrei.
Sollte der Switch Scheiße sein, habe ich auch kein Problem einen anderen zu kaufen... ;-)

Viele Grüße

Pronet36

[arnog]

@pronet36

Ich denke, dass die Telekom von sich aus schon die Multicast-Pakete priorisiert - habe da aber bisher keine Pakete protokolliert, um das mit Sicherheit sagen zu können. Die Pakete sollten also schon in der richtigen "Reihenfolge" priorisiert bei dir ankommen. Dein internes, kabelgebundenes Netz sollte in jedem Fall schneller sein als die externe Anbindung. Deswegen kann ich mir im Moment nur den Switch als Übeltäter vorstellen.

Hast du beim Wechsel auf die pfSense den Tarif bzw. die Bandbreite umgestellt? Falls der Switch die Probleme verursacht, könnte das ein Grund sein, wieso es vorher lief, jetzt aber nicht mehr.

Was Du mal testen könntest, um zu sehen, ob der Switch die Probleme macht: Klemm mal Deine(n) WiFi Access Point(s) ab und schalte das IGMP Snooping aus(!). Dann teste mal bei einer längeren Session, ob du noch Aussetzer hast. Falls nein, parallel mal kabelgebunden einen Download starten. Falls das auch alles ohne Probleme geht, IGMP-Snooping wieder einschalten. Wenn jetzt Aussetzer auftreten, ist der Switch überfordert. Die WiFi Access Points dürfen dabei nicht angeschlossen sein, weil Multicast-Verkehr im WiFi mit einer festgesetzten, recht niedrigen Datenrate übertragen wird. Wenn Du die WiFi Access Points für den Test abklemmst und den Download mit Kabel startest, verhinderst Du, dass Du wegen der Multicast-Problematik im WiFi wieder andere Testartefakte bekommst.

Eigentlich wird Multicast-Verkehr in einem LAN wie Broadcast behandelt, das heißt, alle Multicast-Pakete werden an alle Ports eines Switches weitergeleitet. Wenn Du IGMP Snooping aktivierst, passieren zwei Sachen: der Switch liest IGMP-Nachrichten mit und merkt sich, an welchem Port ein Host einer Multicast-Gruppe beigetreten ist. Wenn dann Multicast-Verkehr reinkommt, filtert der Switch den Multicast-Verkehr und leitet die Pakete nur an die Ports weiter, an denen ein Host der entsprechenden Multicast-Gruppe beigetreten ist. Wenn also IGMP-Snooping ausgeschaltet ist, landet der komplette Multicast-Verkehr auch an den Ports, an denen die WiFi Access Points angeschlossen sind (und nicht alle WiFi Access Points beherrschen selber IGMP Snooping).

[maclake77]

Mein System basiert auf pfSense 2.5.1
Hat es damit schon jemand probiert? Ich habe das Problem, dass ich alles gemäß dieser Anleitung konfiguriert habe aber nach ca. 5 Sek bleibt das Bild quasi stehen. Also dann wenn von Unicast auf Multicast umgeschaltet wird.
Ich habe den Reciever direkt an der pfSense (apu2) dran und bin jetzt überfragt was ich noch tun muss damit es fluscht. Hat von euch lieben jemand noch eine Idee? grüße

[ProNet36]

@maclake77

Die Allows IP Option hast du aktiviert?

[maclake77]

@pronet36
danke für die schnelle Antwort. ja wie gesagt habe mich an das Tutorial gehalten

[arnog]

Kannst du mal Screenshots von deiner Konfiguration posten? Ohne diese Informationen ist es schwierig zu sehen, was das Problem sein könnte.

[maclake77]

@arnog

vielleicht kannst du mir noch sagen, wie ich an die Logs des igmpproxy noch herankomme. Achso und noch der Hinweis dass ich den Reciever zum Testen im "normalen" LAN hatte, nicht im VLAN_IPTV

[arnog]

Kann es sein, dass pfBlocker Multicast-Verkehr blockiert? Vielleicht mal übergangsweise ausschalten und dann nochmal probieren.

[maclake77]

@arnog

gute Idee, aber hatte ich auch schon probiert. Multicast geht einfach nicht durch. Wurde bei Version 2.4.5 wieder was kaputt repariert?

[JeGr]

@maclake77 said in [HowTo] MagentaTV mit pfSense 2.4.5:

@arnog

gute Idee, aber hatte ich auch schon probiert. Multicast geht einfach nicht durch. Wurde bei Version 2.4.5 wieder was kaputt repariert?

Nein aber 2.4.5 hat(te) einen igmpproxy der nicht ganz aktuell ist und in dem es von Upstream Bugs gab die nicht gefixt wurden. 2.5(.x) hat einen aktuelleren bei dem das angeblich nicht mehr der Fall ist bzw. bringt zusätzlich noch ein weiteres Paket mit, das helfen kann.

[maclake77]

@jegr

was kann ich noch probieren damit das bei mir mit Version 2.5.1 flutscht. Wie komme ich an die Logs des igmpproxy?

[arnog]

Du kannst auf der Konfigurationsseite des IGMP-Proxys das Verbose Logging einschalten und kannst dann die Ausgabe da ansehen, wo die anderen Logs auch angezeigt werden.

Was wird dir denn in der Spalte "States" angezeigt für diese Regeln, nachdem du einen Kanal gewechselt hast?

Die IP-Adresse für das Downstream-Interface ist auch korrekt für das LAN?

Bei mir läuft die Konfiguration wie oben zuletzt unter pfSense 2.4.5. Habe noch nicht aktualisiert.

Hast du die pfSense auch direkt an einem Modem angeschlossen oder wie läuft das bei dir?

[maclake77]

@arnog

Hier ein Screenshot der igmp States:

Das Downstream Interface ist korrekt.
Die pfSense hängt an einem ALLNET ALL-BM200VDSL2V (Bridge Modus)

[arnog]

Ich meinte eigentlich "Firewall / Rules / WAN" und "Firewall / Rules / LAN". Da kann man dann sehen, ob die Regeln überhaupt alle greifen bzw. ob entsprechender Verkehr überhaupt durch die Regeln durchläuft. Kannst du die vielleicht nochmal zeigen? Ich stochere gerade auch ehrlich gesagt etwas im Dunkeln.

Du hattest irgendwo noch geschrieben, dass der Receiver jetzt direkt an der APU hängt. Wie bist du denn dann gleichzeitig mit dem Webinterface verbunden? Ein kleines Bild mit dem Setup wäre hilfreich.

[maclake77]

@arnog

die Screenshots der WAN und LAN Regeln hatte ich doch oben schon gepostet.

ja Testweise war der Reciever direkt an der pfSense dran um mögliche Unstimmigkeiten mit der Switchkonfiguration ausschliessen zu können dann erreiche ich natürlich das Webinterface nicht mehr

[arnog]

Bei den States in den Screenshots oben sind bei den States alle Counter 0, so als ob du gerade neu gestartet hast. Da kann man nicht sehen, ob diese Regeln überhaupt matchen.

[maclake77]

@arnog

stimmt dann hier nochmal die aktuellen Screens. Danke für deine Geduld ;)