最近注册了 Cincinnati Bell Fioptics FTTH 和 IPTV。用 pfsense 盒子 + Ubiquiti AP 替换了提供的无线路由器，互联网运行良好。但是，我无法让 IPTV 盒子工作。我读了互联网上关于 Fioptics IPTV 网络的每一篇帖子，以及来自 @Mech 的许多帖子，但都没有成功。
以下是我所拥有的：
pfSense 2.5.2-发布
IGMP 已启用，WAN 上行 10.0.0.0/8，LAN 下行 239.0.0.0/8
IGMP WAN 通行规则，UDP IPTV 流量通行
IGMP LAN 通行规则
所有规则都选中了“允许带有 IP 选项的数据包通过”复选框。在防火墙系统日志中，我看到 WAN 和 LAN 上的 IGMP 流量匹配，这表明 IGMP 流量正在成功流动，但实际的多播流量并非如此。
只有一个 WAN 接口和一个 LAN 接口。没有 VLAN、PPPoE 或任何类似的东西。
作为调试的一部分，我将 pfsense 盒子上的两个端口设置为桥接器，并通过它们连接 ISP 提供的路由器，以捕获流量。我将桥接器设置为接口，创建“通过所有 IPV4”规则，并启用“允许带有 IP 选项的数据包到低音”框，此时电视开始工作。捕获流量确认所有 Fioptics IPTV 流都来自 10.0.0.0/8，并按照建议发往 239.0.0.0/8这里有《Fioptics（辛辛那提贝尔 IPTV）权威指南》。
Wireshark 捕获
我尝试在桥接接口中制定规则以专门匹配 IPTV 流量（来自 10.0.0.0/8 的 IPv4 UDP），但无法让规则匹配任何流量，尽管我可以在数据包捕获中看到它。这对我来说意味着数据包是在链路层而不是防火墙上路由的，这是因为桥接的原因。
我还确保我正在使用 ISP DNS 服务器来消除可能出现的问题。
有人有什么想法吗？随口说说：我是否需要向 IGMP 代理添加更多网络？我的直通规则是否不够用？我的盒子是否在接口处丢弃了所有链路层多播数据包，以至于它们根本无法到达防火墙？
答案1
好的，我让它工作了，现在可以通过 pfSense 路由器成功观看 Fioptics IPTV。有两个问题 - 一个是问题中显示的配置更改，另一个是我单独发现的。
第一个问题：需要将 224.0.0.0/8 添加到下游的 IGMP 代理，如下所示：
有趣的是：239 是 11101111，而 224 是 11100000，因此它们都位于 224.0.0.0/4 掩码下。我确实看到一些发往 225.xxx (11100001) 的 IGMP 数据包 - 因此我想知道 224.0.0.0/4 是否实际上是“更正确”的下游 IGMP 网络。
第二个问题：DNS。为了隔离所有往返于 IPTV 盒的流量，我设置了第二个 LAN 端口（称为 IPTV），并只将 IPTV 盒切换到该端口。捕获流量显示，盒子启动时做的第一件事是对 entm.iptv.zoomtown.com 进行 DNS 查询（然后在每个查询成功解析后依次进行一系列其他查询）。
我最初将 pfsense 配置为使用 1.1.1.1 作为 DNS 服务器，但它无法解析该主机名。然后，我允许 ISP DHCP 配置 DNS 服务器，但提供的默认服务器也无法解析该名称。只有 DNS 服务器 ns1.fuse.net (216.68.1.100) 和 ns2.fuse.net (216.68.2.100) 可以解析它们。这些必须在 ISP 提供的路由器上配置。但是，我不希望所有 DNS 查询都转到这些服务器，因此我将常规设置下的 DNS 服务器重新配置为 1.1.1.1 和 1.0.0.1，然后将 IPTV 接口的 DHCP DNS 服务器（服务 -> DHCP 服务器 -> IPTV）设置为两个 fuse 服务器。这似乎解决了问题。
1月1日22日更新：
辛辛那提贝尔公司已经进行了一些更改。现在需要在 IGMP 代理中包含 172.16.0.0/12。我还没有调查是否仍然需要 10/8。他们大约在两周前进行了第一次更改，我将 172.0.0.0/8 添加到 IGMP，这个功能一直有效，直到现在，/12 版本才是必需的，即完整的 172.16.xx 私有 IPV4 地址空间。注意，我还将下游切换为 224/4。
1 月 17 日 22 点更新：
猫捉老鼠的游戏还在继续。必须将 172.17.0.0/16 添加到 IGMP 代理。这是 172.16/12 的一个子集，所以我还不确定为什么，但它又能正常工作了。
7月8日22日更新：
事实证明，IGMP 设置在 224.0.0.0/4 是正确的。问题出在 IGMP 代理服务崩溃。这似乎与 Fioptics IPTV 多播数据包本身有关。“修复”是安装 Service Watchdog 插件，以便在 igmpproxy 服务崩溃时自动重新启动它。谜团解开了！