Tutorial: Linux firewall and IPTV (e.g. Swisscom TV)

Swisscom TV like any IPTV network really, relies on two technologies to deliver its content to its users:

• Multicast adressing
• IGMPv3
• (IGMP snooping)

 I probably don't need to explain what Multicast is. You should only know that this is what has been causing network administrators many headaches!
Netflix and YouTube don't use Multicast but Unicast instead, only YOU are receiving a particular stream. This is the difference between Video-on-Demand and IPTV.
Speaking of which, when you are watching shows from the past days on Swisscom TV, it's actually sending Unicast packets.

IGMP allows clients (your TV or Set Top Box) to register itself for multicast traffic. This is basically the protocol that is used to select the TV channel, so that the STB can receive it.

IGMP snooping prevents your home network (possibly even the Wi-Fi network) to be flooded by the video stream packets even though only one TV
 needs them. This is a Level 2 technology implemented in switches.
We won't deal with IGMP snooping here, only with the first two.

This tutorial is based on Debian 7.7 but can work anywhere where IGMPProxy can run.

1. Download IGMPProxy, compile and install it.
2. Swisscom seems to use the following subnets:
   
   213.3.72.0/24
   195.186.0.0/16
   
   We'll add them to the igmpproxy configuration in /usr/local/etc/igmpproxy.conf. I have it configured like this:
   
   quickleave
   
   phyint eth0 upstream  ratelimit 0  threshold 1
           altnet 192.168.1.0/24 # see below
           altnet 213.3.72.0/24
           altnet 224.0.0.0/4
           altnet 195.186.0.0/16
   
   phyint eth1 downstream  ratelimit 0  threshold 1
           altnet 172.16.123.128/29 # see below
   
   phyint lo disabled
   
   My configuration (adapt to your needs):
   eth0 is the WAN interface
   eth1 is the LAN interface
   
   192.168.1.0/24 is the subnet between the Swisscom modem and the firewall
   172.16.123.128/29 is the subnet I dedicated to STB.
   224.0.0.0/4 identifies multicast addresses. It goes from 224 to 240, hence the /4 network mask.
   See the documentation for the meaning of quickleave.
3. Configure the firewall to let said subnets in the INPUT chain. Allow FORWARDing between both interfaces.
   (These instructions are vague on purpose. If you are running a firewall you obviously know your policies and rules better than anyone!
   If you want to be precise you will have to allow for the IGMP protocol with the parameter -p igmp of IPTables for instance).
4. Launch igmpproxy in debug mode, as root:
   igmpproxy -d -v /usr/local/etc/igmpproxy.conf
   
   See if you can watch TV. Look at the addresses. Try to add them to your configuration, relaunch the proxy and see if it works.
5. Schedule igmpproxy to start at boot.
   You can use this script and follow the instructions at the bottom of the page. (Discard the explanations in Russian in-between ;-))
6. Happy TV watching!
   
   
   Here's what the traffic looks like while I've been playing with this:
   (This is with pnp4nagios and the stat_net plugin, which is based on /proc/net/dev.)

I am actually quite surprised by this. It seems to need only 3 MBit/s for one TV (and not recording a second channel). I would have expected from 2 to 3 times more bandwidth usage.
I tried nload just to make sure:

Same observation!
(Possibly because /sys/class/net/eth0/statistics/rx_bytes which nload uses, is filled by the same kernel module as /proc/net/dev, in which case this should be accurate as these are the actual frames read by the Linux kernel.)


If you are getting continuous messages in your syslog:

I tried everything. I can either stop the messages or watch TV. For some reason, the STB sends "upstream" IGMP packets. It's very strange and doesn't make much sense. The IGMP proxy doesn't "proxies" them and the TV runs smoothly.
I figured I could safely ignore these. You should also note that IGMPProxy is a very young project (version 0.1).

I added this near the beginning of /etc/rsyslog.conf::msg, contains, "The source address 172.16.123." ~

and restarted the rsyslog daemon. The messages are finally gone. Another solution is to use another file for IGMPProxy logs.

Keywords: linux, unix, firewall, shorewall, bsd, iptables, netfilter, bluewin tv, swisscom, iptv, multicast,