I want to share how I configured my pfSense system to work with my Prism TV service in Seattle, WA, in case any one else was interested in doing so as well.

I had Prism TV installed yesterday in Seattle with my FTTH gig service. The tech set it up with the Technicolor C2000T router, and then I spent the rest of the day getting it working with my original pfSense setup. After paring my network down to the bare minimum, some trial and error, and a little bit of luck, I was able to get it working using bits of information gathered from a number of other sources and similar setups, and I wanted to gather it all in one place to help others.

Here’s my setup:

CenturyLink FTTH 1 Gbps service
Calix 716GE-I interior ONT
pfSense Router x86-64 2.2.4 (Celeron 1037U mini-PC with dual Intel gigabit NICs (em driver in pfSenese))
WAN connection is type IPoE on tagged VLAN 201
LAN is default 192.16.1.1/24
ZyXEL GS1920-24 network switch
Prism TV service with HD and DVR via Pace IPH8010 STB

I had the FTTH service installed about three weeks ago, and it was originally set up using PPPoE on VLAN 201. I followed other guides here to get that up and running with pfSense without too much difficulty.

I moved everything back to the stock CenturyLink router (the C2000A) before the installer came yesterday so he’d have a normal install to work with. The first thing the installer did yesterday was reprovision my service from PPPoE to IPoE and go through a process of reconfiguring the C2000A router with some QoS (done automatically through some interface on his laptop, it seemed). He then went through the normal set-top box setup process and got it provisioned (had to reboot it a couple extra times, and swap my C2000A for the C2000T when the C2000A started making a high-pitched whine). According to the installer (and mentioned elsewhere on this board and others) Prism TV users are all on IPoE service and still on VLAN 201.

Quick overview at a high level of how the Prism IPTV service works, based on my understanding, anyway. Please correct me if I’m wrong, but this should be good enough to understand what follows:

TV channels are broadcast on the fiber network as multicast UDP streams. Multicast groups are used to direct the traffic to all the subscribing devices (i.e., STBs tuned to that channel).
Multicast groups are managed via the IGMP protocol (not the more common TCP or UDP). This allows the stream to be sent only to the parts of the network that need it (instead of flooding the entire network with traffic). IGMP doesn’t normally pass networks/NAT setups – there needs to be some kind of proxy to relay the IGMP messages between networks.
When you switch to a channel on the STB, it will first start receiving the channel as a regular UDP unicast stream, then send the necessary IGMP messages to going the multicast group and then seamlessly switch to the UDP multicast stream.

That last part is why, when your router isn’t configured correctly, you’ll see a channel freeze 10-15 seconds after switching to it: the STB isn’t able to subscribe to the multicast stream to view the channel. Either the IGMP messages or the UDP packets aren’t making it through the router properly (or both).

So, now that we know what the issue is, we can fix it, and it’s actually pretty straightforward now that we know what we’re trying to do: set up an IGMP proxy and configure the necessary firewall rules to allow the IGMP and UDP traffic.

One thing I got stuck on is that the IGMP proxy service in pfSense requires you to specify the upstream multicast networks. It seems that the equivalent service in WRT firmwares doesn’t require that – you just enable the “IGMP proxy” option and you’re good to go. So far I’ve found two networks that traffic comes from, but there may be others, possibly for channels I don’t have or haven’t tried to view yet. Hopefully other users will report back with any other networks they find and we can maintain a comprehensive list.

First, you need to upgrade the version of igmpproxy that comes with pfSense. Get to a shell on the pfSense machine (either via SSH or the console) and run:

1 2 3 4

pkg pkg update pkg install igmpproxy

This should install the package igmpproxy version 0.1_2,1.

Screenshot: »i.imgur.com/P6Jk0Bs.png

This version of igmpproxy has different command-line arguments than the default version, so we need to update the way it is launched:

1. Go into the pfSense Web UI and navigate to “Diagnostics” -> “Edit File”.
2. Browse to the file “/etc/inc/services.inc”
3. Find the line which reads: “/* NOTE: -d4 means everything LOG_WARNING and smaller */”
4. Edit the line underneath to change -d4 to -v -v:

mwexec("/usr/local/sbin/igmpproxy -v -v {$g['tmp_path']}/igmpproxy.conf");

Screenshot: »i.imgur.com/yrrQL1s.png

5. Save the file

(sources: »forum.pfsense.org/index. ··· .0;nowap and »redmine.pfsense.org/issues/4672)

Now to configure the IGMP proxy
1. Go into the pfSense Web UI and navigate to “Services” -> “IGMP proxy”
2. Click the “+” button to add a new upstream proxy as follows:

Interface: WAN
Description: Prism Upstream
Type: Upstream Interface
Threshold: Leave empty
Networks: 67.12.0.0/15, 151.118.0.0/15

Screenshot: »i.imgur.com/QKPRRAY.png

Save the changes

3: Back at the IGMP proxy screen, click the “+” button to add a new downstream proxy as follows:

Interface: LAN
Description: Prism Downstream
Type: Downstream Interface
Threshold: Leave empty
Networks: Leave empty

Save the changes

Screenshot: »i.imgur.com/XutmhHx.png

4. Your IGMP proxy settings should look like this: »i.imgur.com/wgDyjxO.png
5. Click the “Apply Changes” button in the red banner to restart the IGMP proxy with the new configuration. (Note: in my experience, the page will hang on reloading and if you reload it the “apply changes” message is still there, even though the changes have actually been applied and the service restarted. Not sure why that is.)

I found these networks by looking at the debug messages from the igmpproxy service and from what the firewall was blocking. I only saw one or two IPs in each network in the logs, but I did a whois on the address to find the entire network block and added that, just in case CenturyLink changes things in the future.

Also, some threads on igmpproxy on pfSense said you may have to create an interface using the underlying network adapter for your WAN and give it a fake static IP, just so igmpproxy doesn’t complain about it and refuse to work. I didn’t have to do that here (it may only apply to the outdated version included by default), but YMMV.

Now that the igmpproxy is configured, on to the firewall rules…

1. In the web UI, navigate to “Firewall” -> “Rules”
2. In the WAN tab, add the following rules:

Action: Pass
Interface: WAN
TCP/IP Version: IPv4
Protocol: IGMP
Source: any
Destination: any
Log: unchecked
Description: CenturyLink Prism IGMP Messages
Advanced features -> Advanced options -> Check the box next to “This allows packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.”

Action: Pass
Interface: WAN
TCP/IP Version: IPv4
Protocol: UDP
Source: Network, 224.0.0.0/4
Destination: any
Log: unchecked
Description: CenturyLink Prism Multicast UDP
Advanced features -> Advanced options -> Check the box next to “This allows packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.”

Action: Pass
Interface: WAN
TCP/IP Version: IPv4
Protocol: UDP
Source: Network, 67.12.0.0/15
Destination: any
Log: unchecked
Description: CenturyLink Prism Multicast UDP
Advanced features -> Advanced options -> Check the box next to “This allows packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.”

Action: Pass
Interface: WAN
TCP/IP Version: IPv4
Protocol: UDP
Source: Network, 151.118.0.0/16
Destination: any
Log: unchecked
Description: CenturyLink Prism Multicast UDP
Advanced features -> Advanced options -> Check the box next to “This allows packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.”

NB: 224.0.0.0/4 is the block of reserved multicast addresses. The other two networks are the same as those added to the IGMP proxy configuration.

3. In the LAN tab, edit the “Default allow LAN to any rule” rule and under “Advanced features” -> “Advanced options” -> Check the box next to “This allows packets with IP options to pass. Otherwise they are blocked by default. This is usually only seen with multicast traffic.”

WAN rules screenshot: »i.imgur.com/QO8njQW.png
LAN rules screenshot: »i.imgur.com/OzpoQ9g.png

4. Reload the filter rules

These are the rules that are working for me. It’s more than likely that finer-grained networks or network addresses could be used than what I’ve got, but I haven’t looked into that yet.

Once pfSense is configured, you need to enable IGMP snooping on your switch(es). Well, this is not strictly necessary, but since the UDP multicast stream is sent as (I think) broadcast traffic at the layer 2 level, it’ll be sent out to every port on your switch unless the switch is able to inspect (snoop) the IGMP messages and send the traffic only out to the port(s) with clients of the multicast group. If everything’s hard-wired, this isn’t so bad since the stream doesn’t seem to use a whole lot of bandwidth, but if you’ve got a wireless access point you definitely don’t want the broadcast traffic going over the air (the AP will spend all its time sending traffic to nowhere and clients won’t be able to send or receive much real data). Any halfway decent smart or managed switch should have an IGMP snooping option somewhere in its settings…you should just need to find it and enable it.

On my GS1920-24 (running FW version “V4.10(AAOB.5) | 05/05/2015”), which has a very non-intuitive menu system, it’s in “Advanced Application” -> “Multicast” on the left menu, then click on the “Click Here” link next to “IPv4 Multicast” in the right pane, then “IGMP Snooping” on the next screen. I just needed to enable the checkbox next to “Active”, then click the “Apply” button at the bottom to save and activate the new setting, then “Save” up in the top banner to save the running config to flash so it persists across switch reboots. I didn’t have to change any other settings or port configuration.

My GS1920-24 config screenshot: »i.imgur.com/mo89tZc.png

Your switch will likely differ (and I hope it’s easier than mine). All switches that are between your router and your STB (including any build into, e.g., consumer routers you’re running in AP mode) will need to have IGMP snooping enabled.

The next step is to add the appropriate QoS service to prioritize the IPTV traffic across your network (this is done by default in the C2000A and C2000T routers). I haven’t done that yet, but as soon as I get it set up I will add it to this document.

I’ve successfully recorded programs, paused live TV, and viewed free on-demand content with this configuration.

I hope this information has been helpful to others. If you see anything that needs clarification or more information, or have any questions/need help, please let me know and I will do my best to assist.