Comment 41 for bug 447442

I had done the following test:

iptables -t nat -I POSTROUTING 1 -d 224.0.0.0/4 -s 129.168.122.0/24 -j ACCEPT

This adds a rule that presumably intercepts all multicast traffic from VMs and simply accepts it.

A VM is started and receives the IP address 192.168.122.239, which is in the above source subnet 129.168.122.0/24.

This VM now starts pinging for example 8.8.8.8.

iptables -t nat -L POSTROUTING -n -v

Chain POSTROUTING (policy ACCEPT 64 packets, 4057 bytes)
 pkts bytes target prot opt in out source destination
    0 0 ACCEPT all -- * * 129.168.122.0/24 224.0.0.0/4
    0 0 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
    0 0 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
    1 84 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24

Above shows a counter of '1' indicating the masquerading of the ICMP traffic. Stopping and restarting the ping puts the counter to '2'. (due to connection tracking the rule is only needed once per ICMP stream)

I started a 'tcpdump -i vnet0 -n' to monitor traffic from that VM.

Inside the VM I did

service avahi-daemon restart

which then shows a flood of multicast messages on vnet0. One would think that that traffic now gets 'ACCEPT'ed due to the 1st rule above, but this is not the case. The output of

iptables -t nat -L POSTROUTING -n -v

still shows the same as above -- no counter change in the 1st ryule. The kernel was 2.6.35.14-97.fc14.x86_64.
Changing above first rule to '-j MASQUERADE' or '-j RETURN' doesn't change a anything. The counter remains on '0'.

My conclusion is that adding a rule here (for this kernel version at least) for multicast traffic makes no sense since it doesn't get invoked. Also see comment 12.