Pfsense + Cincinnati Bell Fioptics IPTV

Recently signed up for Cincinnati Bell Fioptics FTTH with IPTV. Replaced the provided wireless router with a pfsense box + Ubiquiti AP and the internet works great. However, I cannot get the IPTV boxes to work. I've read every post the internet has about Fioptics IPTV networking, and many posts from @Mech, with no luck.

Here's what I have:

pfsense 2.5.2-RELEASE

IGMP enabled, WAN upstream 10.0.0.0/8, LAN downstream 239.0.0.0/8

screenshot

IGMP WAN pass rule, UDP IPTV traffic pass

screenshot

IGMP LAN pass rule

screenshot

All rules have the "Allow packets with IP options to pass" box checked. In the Firewall System Logs I see IGMP traffic matches on both WAN and LAN, suggesting that IGMP traffic is flowing successfully, but not the actual multicast traffic.

Only one WAN interface and one LAN interface. No vlans, PPPoE, or anything fancy like that.

As part of my debugging, I set up two of the ports on the pfsense box as a bridge and connected the ISP provided router through them in order to capture the traffic. I set the bridge as an interface, created a "pass all IPV4" rule, and enabled the "Allow packets with IP options to bass" box, at which point the TV started working. Capturing the traffic confirmed that all Fioptics IPTV streams originate from 10.0.0.0/8 and are destined for 239.0.0.0/8 as suggested here in this “Fioptics (IPTV by Cincinnati Bell) Definitive Guide”.

Wireshark capture

screenshot

I tried to make rules in the bridge interface to match the IPTV traffic specifically (IPv4 UDP from 10.0.0.0/8), but could not get the rules to match any traffic even though I could see it in Packet Capture. This suggests to me that the packets were being routed at the link layer and not the firewall due to the bridge.

I also made sure I am using the ISP DNS servers to eliminate that as a possible issue.

Does anyone have any ideas? Spitballing: Do I need to add more networks to the IGMP proxy? Are my pass-through rules not adequate? Is my box dropping all link-layer multicast packets at the interface so they never even get to the firewall?


Ok, I got it working and am successfully watching the Fioptics IPTV right now thru the pfsense router. There were two problems - one change to the configuration shown in the question, and another I discovered separately.

First problem: 224.0.0.0/8 needs to be added to the IGMP proxy downstream, like this: enter image description here Interesting note: 239 is 11101111 and 224 is 11100000, so these are both under a 224.0.0.0/4 mask. I do see some IGMP packets destined for 225.x.x.x (11100001) - so I wonder if 224.0.0.0/4 is actually the "more correct" downstream IGMP network.

Second problem: DNS. In order to isolate all traffic to/from the IPTV box, I set up a second LAN port (called IPTV), and switched only the IPTV box over to it. Capturing the traffic revealed that the first thing the box does when it boots is a DNS query for entm.iptv.zoomtown.com (and then a series of others sequentially after each one resolves successfully).

I had configured pfsense originally to use 1.1.1.1 as the DNS server, which does not resolve that hostname. Then, I allowed the ISP DHCP to configure the DNS servers but the default ones provided also would not resolve that name. Only the DNS servers ns1.fuse.net (216.68.1.100) and ns2.fuse.net (216.68.2.100) will resolve them. These must have been configured on the ISP provided router. I did not want all DNS queries to go to these servers however, so I re-configured the DNS servers under General Setup to be 1.1.1.1 and 1.0.0.1, then set the DHCP DNS servers for the IPTV interface (Services -> DHCP Server -> IPTV) to the two fuse servers. That seemed to fix it.

Update Jan 22:

Cincinnati Bell has been making some changes. It is now necessary to include 172.16.0.0/12 in your IGMP proxy. I have not investigated if 10/8 is still required. They made the first changes roughly two weeks ago and I added 172.0.0.0/8 to the IGMP, which worked until now, at which point the /12 version is necessary, which is the full 172.16.x.x private IPV4 address space. Note I also switched the downstream to 224/4.

enter image description here