multicast traffic is able to poke a hole into the netfilter connection tracking system

Question

I have an IPTV solution at home where the ISP sends me hundreds of large UDP datagrams per second from 10.4.4.5 port 10 to 239.3.5.3 port 10, i.e. it is using multicast. My current iptables configuration for ingress traffic is very simple:

~# iptables -L INPUT -v -n --line-numbers
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       19   845 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
2     1146  275K ACCEPT     all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED /* established/related connections */
# 

Rules in iptables-save format:

# iptables-save -c
# Generated by iptables-save v1.6.0 on Sun Aug 26 12:51:11 2018
*nat
:PREROUTING ACCEPT [44137:4586148]
:INPUT ACCEPT [6290:1120016]
:OUTPUT ACCEPT [419:75595]
:POSTROUTING ACCEPT [98:8415]
[26464:2006874] -A POSTROUTING -o eth0 -m comment --comment SNAT -j MASQUERADE
COMMIT
# Completed on Sun Aug 26 12:51:11 2018
# Generated by iptables-save v1.6.0 on Sun Aug 26 12:51:11 2018
*filter
:INPUT DROP [72447:97366152]
:FORWARD ACCEPT [77426:101131642]
:OUTPUT ACCEPT [148:17652]
[17:787] -A INPUT -i lo -j ACCEPT
[333:78556] -A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -m comment --comment "established/related connections" -j ACCEPT
COMMIT
# Completed on Sun Aug 26 12:51:11 2018
# 

eth0 seen above is the ISP-facing NIC. Now the weird part is that while this multicast traffic gets dropped according to counters(chain default policy counter increases several MB/s), then actually I do receive it in mplayer. The reason for this is that multicast traffic seems to create a hole into netfilter connection tracking system. I can verify this with conntrack -L. Example:

# conntrack -L | grep --color 239.3.
udp      17 29 src=10.4.4.5 dst=239.3.5.3 sport=10 dport=10 [UNREPLIED] src=239.3.5.3 dst=10.4.4.5 sport=10 dport=10 mark=0 use=1
conntrack v1.4.4 (conntrack-tools): 130 flow entries have been shown.
# 

Even if I execute conntrack -F, then this entry above reappears and I can see the video stream in mplayer. However, eventually(after ~5 minutes) this entry disappears and also immediately the stream stops.

Just for information, this Linux-based router has 9 physical interfaces:

# ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP> 
eth2             DOWN           00:a0:c9:77:96:bd <NO-CARRIER,BROADCAST,MULTICAST,UP> 
eth1             UP             00:14:bf:5f:de:71 <BROADCAST,MULTICAST,UP,LOWER_UP> 
eth0             UNKNOWN        00:50:8d:d1:4f:ee <BROADCAST,MULTICAST,UP,LOWER_UP> 
eth3             DOWN           00:a0:c9:4b:21:a0 <NO-CARRIER,BROADCAST,MULTICAST,UP> 
eth4             UP             00:20:e2:1e:2e:64 <BROADCAST,MULTICAST,UP,LOWER_UP> 
eth5             DOWN           00:20:fc:1e:2e:65 <NO-CARRIER,BROADCAST,MULTICAST,UP> 
eth6             DOWN           00:20:fc:1e:2e:8e <NO-CARRIER,BROADCAST,MULTICAST,UP> 
eth7             UP             00:20:fc:1e:2f:67 <BROADCAST,MULTICAST,UP,LOWER_UP> 
wlan0            UP             00:21:91:e3:20:20 <BROADCAST,MULTICAST,UP,LOWER_UP> 
br0              UP             00:14:bf:5e:da:71 <BROADCAST,MULTICAST,UP,LOWER_UP> 
# ip -br address
lo               UNKNOWN        127.0.0.1/8 
eth2             DOWN           
eth1             UP             
eth0             UNKNOWN        192.0.2.79/24
eth3             DOWN           
eth4             UP             
eth5             DOWN           
eth6             DOWN           
eth7             UP             
wlan0            UP             
br0              UP             192.168.0.1/24
# 

As I told, eth0 is connected to ISP. eth1 to eth7 plus wlan0 are part of bridge named br0. Routing table looks like this:

# ip -4 r
default via 192.0.2.1 dev eth0 
192.0.2.0/24 dev eth0 proto kernel scope link src 192.0.2.79 
192.168.0.0/24 dev br0 proto kernel scope link src 192.168.0.1 
# 

Various network parameters for all the interfaces can be seen here:

# ip -4 netconf 
ipv4 dev lo forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth2 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth1 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth0 forwarding on rp_filter off mc_forwarding on proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth3 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth4 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth5 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth6 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev eth7 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev wlan0 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
ipv4 dev br0 forwarding on rp_filter off mc_forwarding on proxy_neigh off ignore_routes_with_linkdown off 
ipv4 all forwarding on rp_filter off mc_forwarding on proxy_neigh off ignore_routes_with_linkdown off 
ipv4 default forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off 
# 

Is this an expected behavior? My first thought was that conntrack module is able to inspect the IGMP "membership report" messages and thus allows traffic to 239.3.5.3, but this doesn't explain, how traffic is allowed even after conntrack -F.

Answer 1

After trying a similar setup using pimd, I can only conclude that:

• normal (data) multicast packets are forwarded so are subject to filter/FORWARD as long as multicast routing is enabled for this flow. The conntrack entry udp 17 29 src=10.4.4.5 dst=239.3.5.3 sport=10 dport=10 [UNREPLIED] src=239.3.5.3 dst=10.4.4.5 sport=10 dport=10 mark=0 use=1 is such a forwarded flow and will also increment the nat/PREROUTING and nat/POSTROUTING counters by (only) one: the NEW packet that triggered this contrack entry.
• link-local multicast packets (IGMP packets to 224.0.0.{1,22} and PIMv2 to 224.0.0.13) are stopped by filter/INPUT.
• if the flow was enabled before, the multicast router will then activate forwarding of this specific multicast destination for a while. Once a configured timeout occurs during which it didn't receive any IGMP report from LAN or PIMv2 from WAN because of the firewall, it will consider there is no client listening anymore or no valid flow anymore and will stop forwarding the corresponding multicast flow.

In the end, you should allow the linux router to receive:

• IGMP packets coming from LAN, to allow the router to keep knowing which multicast clients are listening:

  iptables -A INPUT -i br0 -p igmp -j ACCEPT
  

• My specific setup is using pimd and PIMv2, I don't know if this protocol is always used or not, but I had to allow the PIM protocol for it to work while keeping the DROP policy, when the source IP wasn't just 192.0.2.1 (but 10.4.4.5):

  iptables -A INPUT -s 192.0.2.1 -i eth0 -p pim -j ACCEPT
  

• It might be needed to allow IGMP packets from the ISP router, but my specific setup didn't require them:

  iptables -A INPUT -s 192.0.2.1 -i eth0 -p igmp -j ACCEPT
  

UPDATE:

Note that the filter/INPUT chain's DROP policy will still show hits: the linux router's own IGMP and PIMv2 packets, being multicast, are looped back to the local system when sent outside and are thus (harmlessly) dropped since not enabled by the rules above. After adding the corresponding rules, I hit a strange behaviour for PIMv2 and in the end I had to mark packets in filter/OUTPUT to allow their looped back copy in filter/INPUT. While at it I also restricted the nat rule. In the end, with the following rules, the filter/INPUT's DROP policy counter always stayed at [0:0] while forwarding multicast traffic:

# Generated by iptables-save v1.6.2 on Mon Aug 27 01:01:48 2018
*nat
:PREROUTING ACCEPT [1:56]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [1:56]
[0:0] -A POSTROUTING -s 192.168.0.0/24 -o eth0 -m comment --comment SNAT -j MASQUERADE
COMMIT
# Completed on Mon Aug 27 01:01:48 2018
# Generated by iptables-save v1.6.2 on Mon Aug 27 01:01:48 2018
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [1533311:325676232]
:OUTPUT ACCEPT [75:3724]
[0:0] -A INPUT -i lo -j ACCEPT
[1:56] -A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
[40:1800] -A INPUT -i br0 -p igmp -j ACCEPT
[14:774] -A INPUT -s 192.0.2.1/32 -i eth0 -p pim -j ACCEPT
[28:1288] -A INPUT -s 192.0.2.1/32 -i eth0 -p igmp -j ACCEPT
[17:932] -A INPUT -s 192.0.2.79/32 -i eth0 -p igmp -j ACCEPT
[28:1392] -A INPUT -m mark --mark 0x1 -j ACCEPT
[28:1392] -A OUTPUT -p pim -j MARK --set-xmark 0x1/0xffffffff
COMMIT
# Completed on Mon Aug 27 01:01:48 2018

You can simulate a multicast client and dump to stdout with socat (specify the local IP if more than one interface):

socat -u UDP4-RECV:10,ip-add-membership=239.3.5.3:0.0.0.0 -