pfsense IGMP Proxy: TV-Box interrupts live stream after a few minutes

  • Values ​​SCC

    I set up a pfsense firewall at home (FTTH, connected directly with media converter).

    The following phenomenon occurs with SCTV 2.0: If I watch a live stream, the stream interrupts after a few minutes and a black screen appears with the message “Unfortunately, there is no signal available from this station at the moment”.

    If you get to the bottom of the matter further, you can see in Wireshark that the TV-Box first registers correctly with the corresponding multicast group (correspondingly, the stream runs perfectly via multicast). However, with the subsequent ‘membership query’ of the IGMP proxy, the TV box always sends back a ‘leave group’, which of course leads to the stream being interrupted.

    This behavior is independent of whether the TV box is connected directly to the pfsense or is connected via a switch (Netgear GS108E with activated IGMP snooping).

    Time-shifted television works without any problems, as this is not multicast.

    Has anyone had any experience with this, any ideas or suggestions as to what else we could try? I didn’t change the IGMP proxy configuration, I just entered the corresponding addresses (downstream/upstream) in the configuration GUI.

    With best regards

    iptables

    Show original language (German)

    Yes, I have also configured the firewall rules accordingly. Wireshark also shows nicely multicast traffic at TV-Box, up to the point at which the box sends the ‘leave group’ message…

    Show original language (German)

    Did it ever work at all? e.g. with version 2.2.6 and now no longer with 2.3?

    How did you configure the WAN? Is the VLAN tagged on the pfsense or on the converter hardware?

    Show original language (German)

    Regardless of the version, I always had the interruptions and was content to watch TV with a 10-second delay. The VLAN is tagged on the pfsense.

    Now I looked at the firewall rules again (for what felt like the 100th time) and actually saw that the WAN address was entered as the destination for the “PASS: IGMP” rule on the WAN interface. After changing the destination to any and a reboot it now seems to work 🙂

    It’s just strange that I didn’t notice this sooner…Thank you for your input.

    iptables

    Show original language (German)

    Ok then everything is fine again.

    I was still thinking about a bug in the igmp proxy in the current version, which apparently doesn’t use the VLAN interface. This particularly affects the Germans and could have come into play in this case.

    https://redmine.pfsense.org/issues/6099

    I can’t test things like this myself at the moment because the services at my SME Office are separate from the Internet (if you use PPPoE passthrough).

    Show original language (German)

    Luckily it doesn’t seem to be related to this bug…it’s a big topic there 😮

    Small addendum to the FW rules: with the PASS: IGMP rule you can limit it to 224.0.0.0/4 if you don’t want to use ANY as the destination. At least I didn’t notice any problems with it yesterday…that should be correct, right?

    Best regards

    ip

    Show original language (German)

    Yes, you can do it like that.

    In the end, it’s not really relevant. Only multicast traffic permitted by the network provider is on the network.

    Theoretically, you could specifically allow IPTV streams or not.

    I don’t think this is relevant to security and have never done so. The real problem lies with the network provider itself, which cannot limit the streams to its customers.

    I think people are very lazy there and don’t do it out of convenience because it would also be an additional effort.

    Show original language (German)
    5 months later

    @Tux0ne

    @iptables

    Hello everyone,

    I have the same problem that the IGMP proxy on the pfsense doesn’t really run stable (I use an APU2 board from pcengines.ch as hardware).

    Since version 2.3.x it is even worse than with 2.2.x

    I have the Swisscom Standard Internet Box in DMZ mode, which points to the WAN interface of the PFSense.

    IGMP Proxy is configured as follows

    Interface LAN, type downstream 192.168.151.0/24

    Interface WAN, type upstream 224.0.0.0/4, 195.186.0.0/16, 213.3.72.0/24

    To do this, I created a network alias grp_SwisscomTV_Infrastructure, which contains the following addresses:

    195.186.0.0/16 Swisscom TV

    213.3.72.0/21 Swisscom TV 2.0

    224.0.0.0/4 Multicast

    239.186.0.0/16 Inbound Stream

    Firewall rules on the WAN interface:

    IPv4 IGMP Any:Any Any:Any

    IPv4 UDP grp_SwisscomTV_Infrastructure:any grp_SwisscomTV_Infrastructure:any

    Firewall rules on the LAN interface:

    IPv4:ANY LAN net:any grp_SwisscomTV_Infrastructure:any

    What did I forget :-)?

    Show original language (German)

    At first glance, I’m missing the Advanced Option with allow Packets with IP Options.

    But maybe ishan @dicBoHift can say more. I think he still has a setup like that in use.

    Not me. Swisscom services are outside my IP network which I need for my things.

    Show original language (German)

    @Tux0ne

    hi Tuxone,

    I set “Allow IP options” on the IGMP rule on the WAN interface.

    I have now set up the following on the LAN interface, but I don’t know whether this is necessary. in your blog entry, you simply have Any open here…

    IPv4:Any grp_SwisscomTV_Infrastructure:Any grp_SwisscomTV_Infrastructure:Any

    But I don’t think that the Swisscom TV Box uses packets with SRC from the multicast range…

    I currently have Swisscom TV in a separate VLAN and route it around my other subnets and Pfsense…

    Show original language (German)
    a month later

    Sali @tohil

    I was busy moving last week and was only able to take a closer look at your post now. I have pfSense 2.3.2 running on a pcengines APU1d4, but connected directly to the glass via a media converter. Things have been working perfectly for me since I adjusted my FW rule (see above).

    I don’t know whether it has a connection with the DMZ mode, the Internet box is more of a black box… I have no idea what’s going on in it in the said mode… one thing or another is probably not going to the IP of the pfSense WAN if pictured 😕

    The only thing I noticed in your FW rules - which is probably more of a cosmetic flaw - is in your alias grp_SwisscomTV_infrastructure.

    224.0.0.0/4 is 224.0.0.0 - 239.255.255.255, so 239.186.0.0/16 is already included and does not need to be mentioned separately.

    Best regards

    ip

    Show original language (German)

    @iptables

    Thanks for the tip, I adjusted the alias and removed 239.186.0.0/16!

    Even if it’s just cosmetic, it simplifies the FW rules in the system.

    Yes, I could really throw the sorry Internet box in the bin. I really don’t understand why you can’t activate a bridge mode and agree that Swisscom can’t guarantee support for anything else.

    During the live stream, there are interruptions for different lengths of time every minute, or there are fragments in the image.

    In addition, rewinding is sometimes not possible and an error message appears…

    Greeting

    Show original language (German)

    @tohil

    That really sounds a bit strange… I’m not sure if the worm is really in the IGMP proxy. The fact that rewinding sometimes doesn’t work makes me a bit suspicious. The time-shifted streams are completely normal TCP streams, which are initiated from the TV-Box.

    Wireshark was a huge help to me back then, as it allowed me to see what traffic was running on the network and thus gave me a better understanding of error analysis.

    This little summary might already be helpful (my findings from the Wireshark recordings from the mirrored TV-Box port):

    TV-Box is 192.168.1.33

    pfSense is 192.168.1.1

    If I switch to a new channel, the first 10s are a unicast udp stream (213.3.76.5 -> 192.168.1.33).

    10s later the following happens: 192.168.1.33 sends an IGMP membership report to the multicast address of the corresponding transmitter (e.g. 239.186.68.1 for SRF1) to join the stream. The multicast udp stream then begins to flow (213.3.72.5 -> 239.186.68.1)

    If I switch to another station, the box sends a leave group ‘239.186.68.1’ via IGMP to the destination address 224.0.0.2 (all routers on this subnet). And the game starts again.

    As I said, time-shifted television is a unicast tcp stream, for example 213.3.74.22 -> 192.168.1.33.

    I hope that sheds some light on the matter…I could of course also have fun digging the Internet box out of the basement and testing whether I would have similar problems with the DMZ mode…but I’m dreading that, as we all know don’t wake sleeping dogs ^^

    Do you occasionally get the black screen “Unfortunately there is no signal available from this TV channel at the moment” when you interrupt the live stream?

    What does the error message say when rewinding?

    Cheers

    P.S. I discovered another small cosmetic error: SCTV2.0 is 213.3.72.0/24 and not 213.3.72.0/21 😉

    Show original language (German)

    @iptables

    Good morning,

    Yes, a time delay is not a problem, for a known technical reason 🙂

    Winding sometimes simply doesn’t work… the system doesn’t respond and at some point the message “The selection cannot be played back” appears.

    I haven’t had the black screen with “no signal from this station” in a while.

    I also believe that it has to do with the DMZ mode of the Internet Standard Box. Maybe I’ll terminate the Swisscom TV VLAN directly on the router again, instead of behind the pfSense interface…

    Greeting

    Show original language (German)

    @iptables

    @Tux0ne

    Hello iptables,

    I think the network 213.3.72.0/21 was correct. At least I had to adjust it again because certain channels no longer worked and according to the log they were in the 213.3.75.x network.

    I haven’t run a Wireshark yet… but I can see it in the FW log during the stall

    224.0.x.0 on pfSense WAN Interface 192.168.199.2 drop IGMP

    Although IGMP is open to ANY… maybe a problem with expired states?

    Show original language (German)