Fritzbox, entertain, pfsense - und igmpproxy

bringha

Hallo zusammen,

auch wenn das Thema hier schon mehrfach diskutiert wurde: ich habe (noch) nicht ganz aufgegeben, das zum laufen zu bringen: Meine config:

–-----> DMZ
|
VDSL25-----> Fritzbox 3490---->pfsense----+------> LAN
|
--------> WLAN

Aus verschiedenen Gründen kann ich leider nicht auf die Fritzbox verzichten und die bekannte tausys-blog config mit PPPoE und VLAN 7 und VLAN 8 verwenden - so far so bad.

Allerdings gibt es die Live TV Funktion auf der Fritzbox und die würde ich gerne mit VLC Player Clients im LAN nutzen, um Entertain zu machen. Senderliste etc ist ja alles bekannt und ich bin mittlerweile so weit gekommen, dass ich alle Programme für 130 sec sehe, dann stoppt das ganze, fängt aber nach so 5-10 min. von selbst wieder an, - wieder für 130 sec., dann geht das Spiel von neuem los.

Ursache scheint hier ein bizarres Verhalten des IGMP Proxy zu sein: Schaut man sich den IGMP Traffic auf der LAN Seite an, so ist alles OK; der igmpproxy sendet artig alle 130 sec einen general igmp membership query an 224.0.0.1 und der Client antwortet artig, dass er bitte zu den Gruppen 224.0.0.251 (mDNS Requests von MacOS) und 239.35.10.4 (das ist ARD von Entertain/Live TV der FB) gehören möchte. Dies wird auch fortgesetzt, nachdem der UDP Datenstream gestoppt hat. Man kann sich jetzt trefflich darüber streiten, ob es clever ist, die 130 sec fest in den igmpproxy code einzuprogrammieren, und nicht konfigurierbar zu machen, ist aber erst mal so .....) Ebenfalls schade, dass auf der LAN Seite nur IGMPv2 läuft, ist aber auch erst mal so.

Auf der WAN Seite läuft der igmpproxy mit IGMPv3, wie die Fritzbox auch. Der igmpproxy sollte sich hier wie ein CLIENT verhalten. Die Fritzbox sendet ebenfalls einen igmp membership Query an 224.0.0.1. pfsense (muss nicht unbedingt der igmpproxy sein) antwortet dann mit allen möglichen IGMP Gruppen in einem Antwortpaket an 224.0.0.22. Bzgl. des IPTV streams (239.35.10.4) kommt zunächst ein Leave, unmittelbar danach sofort ein Join, 2 sec später nochmal ein Join - und dann nix mehr wieder. Alle regelmäßigen reports auf der LAN Seite führen zu keinem igmp Verkehr auf der WAN Seite mehr. Auf alle nachfolgenden Queries der FB antwortet die pfsense nichts mehr zu 239.35.10.4 . Folgerichtig stoppt dann die Streaming Quelle nach dem Timerablauf den UDP stream. Irgendwann (durch welchen Trigger ?) sendet dann die pfsense wieder ein join, dann das gleiche wieder von vorn!)

Interessant zu sehen ist hier im Vergleich das Verhalten des Entertain Mediareceivers (hängt bei mir direkt an der FB), der auf jeden Query seine aktuelle Programm mcast Adresse artig antwortet.

Leider geben die -v -v Ausgaben des igmpproxies keine brauchbaren Informationen zum WAN Interface. Ich hatte auch meine FW Rules im Verdacht, die sind aber mit erweiterten Optionen für alle igmp rules eingestellt.

Hat jemand irgend eine Idee?

Freue mich auf Eure Antworten

Br br

-flo- 0

Deine pfSense-Config??

-flo- 0

@bringha:

Aus verschiedenen Gründen kann ich leider nicht auf die Fritzbox verzichten und die bekannte tausys-blog config mit PPPoE und VLAN 7 und VLAN 8 verwenden - so far so bad.

Die wären evtl. auch nicht schlecht zu wissen ;-).

bringha

Hi,

Die pfsense läuft als XEN HVM auf einer Debian jessie dom0
igmpproxy ist die Version 0.1

hier meine igmpproxy.conf


##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint xn1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4

phyint xn0 downstream ratelimit 0 threshold 1
altnet 192.168.1.0/32

phyint xn2 disabled
phyint xn3 disabled

xn1 mein WAN, xn0 mein LAN; Lan hat nur ein VLAN1 (default)

Firewall rules:
1.WAN


(...)
e              IPv4 IGMP *	*	224.0.0.0/4	*	*			   		   
e              IPv4 UDP	 *	*	239.0.0.0/4	*	*

2. LAN


e               IPv4 *	LAN net	*	*	*	*		Default allow LAN to any rule	   
  		IPv6 *	LAN net	*	*	*	*		Default allow LAN IPv6 to any rule

e = erweiterte Optionen

Welche andere config wäre noch interessant?

Warum die Fritze?
Habe eine Großfamilie und ein umfassender Umbau würde zuviel Geschrei geben (wg langer downtime, Papas SLA Verletzen, Telefon, mediareceiver läuft endlich stabil….) das ist eine lange Geschichte ..... Wenn ich irgendwann mal einen längeren Urlaub mit mehreren zusammenhängenden Tagen zu Hause habe (allein) dann mache ich mich da mal dran, die rauszuwerfen .... :-\ ::)

Br br

-flo- 0

Ah, jetzt kann man schon was damit anfangen. :-)

@bringha:


##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint xn1 upstream ratelimit 0 threshold 1
altnet 193.158.0.0/15
altnet 224.0.0.0/4

phyint xn0 downstream ratelimit 0 threshold 1
altnet 192.168.1.0/32

phyint xn2 disabled
phyint xn3 disabled

Im Upstream müßte meinem Verständnis nach eigentlich die Adresse der FB konfiguriert sein. Im upstream werden die Netze / Adressen konfiguriert, von dem der IGMPProxy IGMP-Traffic akzeptiert. Das ist hinter der FB nur diese, nicht die öffentlichen Netze der Telekom.

Aus Deiner ersten Beschreibung geht hervor, daß der IGPMProxy nicht auf Anfragen der FB antwortet. Wenn Du das hier änderst, dann sollte sich das ändern. Offenbar kannst Du das tracen, daher kannst Du das ja direkt prüfen. (Die erste Meldung des IGMPProxy muß nicht unbedingt eine Antwort auf die Nachricht der FB sein, das kann auch der IGPMProxy u.U. selbst initiieren.)

Ich habe übrigens kein solches Setup, daher sind das eher sagen wir mal "fundierte Vermutungen".

Noch was: Ich habe in meiner config den Multicast-Bereich 224.0.0.0/24 nicht als upstream konfiguriert. Evtl. willst Du das mal rausnehmen. Das macht zwar nichts kaputt, aber m.E braucht es das nicht. (M.a.W.: Das verursacht nicht Dein Problem.)

@bringha:

xn1 mein WAN, xn0 mein LAN; Lan hat nur ein VLAN1 (default)

Firewall rules:
1.WAN


(...)
e              IPv4 IGMP *	*	224.0.0.0/4	*	*			   		   
e              IPv4 UDP	 *	*	239.0.0.0/4	*	*

2. LAN


e               IPv4 *	LAN net	*	*	*	*		Default allow LAN to any rule	   
  		IPv6 *	LAN net	*	*	*	*		Default allow LAN IPv6 to any rule

e = erweiterte Optionen

Mach mal die Regeln statt auf dem WAN interface als Floating-Regeln. Du willst Multicast und IGMP auf allen Interfaces erlauben.

Ein bißchen Binärarithmetik: 224.0.0.0/4 ist identisch mit 239.0.0.0/4. Du kannst 239. auf 224. ändern, das ist aber nur kosmetisch.

Sonst schränkst Du ja nichts ein, also sollte das kein Problem sein. Weitere Regeln braucht es m.E. nicht.

@bringha:

Warum die Fritze?
Habe eine Großfamilie und ein umfassender Umbau würde zuviel Geschrei geben (wg langer downtime, Papas SLA Verletzen, Telefon, mediareceiver läuft endlich stabil….) das ist eine lange Geschichte ..... Wenn ich irgendwann mal einen längeren Urlaub mit mehreren zusammenhängenden Tagen zu Hause habe (allein) dann mache ich mich da mal dran, die rauszuwerfen .... :-\ ::)

Alles klar.

Du kannst als schnelle Lösung den Mediareceiver natürlich einfach in das LAN-Segment zwischen FB und pfSense FB klemmen. pfSense (WAN-Seite) und MR haben dann eine IP-Adresse im gleichen Subnetz. Dann gibt es ungetrübten Fernsehgenuß für die Familie über den MR. Wenn die FB einen vernünftigen IGMPProxy eingebaut hat, dann müßte die pfSense dennoch Multicast abonnieren können für die VLC-Clients.

bringha

So …

habe das jetzt mal ausprobiert: Offenbar verhält sich die Fritzbox dann NICHT wie ein vollwertiger IGMP Router:

Trage ich die FB als einziges Upstream Netz ein (hier als 192.168.x.0/24) dann sendet sie gar keine generellen IGMP Queries mehr (224.0.0.1). die pfsense sendet dann direkt ihre beiden join Kommandos and 224.0.0.22 für die mcast Gruppe 239.35.10.4. Das wäre dann ja auch erklärlich, da dann ja die generell bogon FW rule zuschlägt ....

Erst mit der angegebenen Stream Quelladresse (193.158.0.0/15) sendet die FB wieder das generelle Query Kommando. Das macht mE auch Sinn: woher sollte die FB sonst wissen, woher die Daten kommen sollen? Und die igmp Routing Infos werden ja über das igmp Protokoll im Adressraum gesteuert.

Trage ich das FB Netz ZUSÄTZLICH als Upstream ein, dann ist die Situation unverändert zu vorher.

Die Angabe der Filterregeln als Floating hat ebenfalls nichts verändert. Ich tippe ja ehrlich gesagt auch immer noch auf den igmpproxy als roae....

Muss ich ggf noch eine Filterregel auf der Fritzbox für mcast ergänzen? Oder gar die pfsense als trusted host angeben? Gibt es da auch noch eine Abhängigkeit, an welchem Port die pfsense hängt (ist bei mir Port 1, sollte NICHT an Port 4 sein (Gastzugang))

... Fragen über Fragen ....

Br br

-flo- 0

Also da strecke ich die Waffen, sorry. Ich habe ja selbst die pfSense direkt am Modem, da funktioniert der igmpproxy leidlich gut. Das vielleicht noch als Vorwarnung wegen "Papa-SLA" :-) : Grundsätzlich klappt das alles mit dem Fernsehen, aber schnelles Umschalten am MR klappt nicht gut mit dem igpmproxy der pfsense.

bringha

@flo Trotzdem Danke für den Versuch…..

Mir ist da noch ein anderer Ansatz untergekommen: Was wäre denn, die pfsense zu einem wirklichen mcast ROUTER aufzubohren? Hat jemand Erfahrungen mit mrouted?

Schliesslich

basiert der code vom igmpproxy in Teilen darauf
gehört das zum Standard Umfang von freebsd (ist aber bei pfsense nicht dabei)

Hat jemand Erfahrung damit?

Br br