I am having a problem where multicast routed packets do not seem to get SNAT applied correctly, at least not consistently. I say SNAT but it is actually a MASQUERADE rule. I am using smcrouted as the routing daemon. It is an embedded system running Xen. The embedded environment has a single Ethernet port. I am attempting to route multicast traffic generated by Xen guest domains through the external interface. The Xen dom0 is configured with the routing options. I do not believe this should matter but it gives some context. I have read through another question on this topic in the mailing list archives. It seems very similar to my configuration. However the solution does not seem to consistently work for me. https://marc.info/?l=netfilter&m=147250124301875&w=2 In the mentioned question the problem was when it had already began routing data before he added his NAT rule. The solution was to use conntrack -F to dump the state. However in my case I control when the multicast is being sent. No state has been created and yet it does not perform NAT correctly when I begin sending the multicast data. The data is routed correctly, but has the internal IP of the Xen guest domain and not the external eth0 interface. I have attempted to verify there is no connection state by running, e.g. conntrack -L -d 224.0.6.240 which reports 0 flow entries. This is before I begin sending multicast data. When I start sending data this will show 1 flow entry. However the output of conntrack -L -n does not show any NAT translation. Additionally I can see with tcpdump that the outgoing packets have the source IP of the internal Xen guest. Interestingly, if I then delete the connection tracking AFTER I start sending multicast packets it seems to begin doing the NAT translation correctly. conntrack -D -d 224.0.6.240 conntrack -L -n This will show that the NAT translation is now taking place and this is confirmed with tcpdump. If I flush all connection tracking with 'conntrack -F' and restart it seems to work correctly afterwards. It seems to be only a problem for the first time before any packets have been routed. If I reboot the system it consistently has problems the first time. I would obviously like to avoid this as it is it would be leaking packets with an incorrect IP for some time. I have noticed this behavior can be affected by other iptables rules. For example during debugging I added the rule 'iptables -t raw -A PREROUTING -d 224.0.6.240 -j TRACE" to add trace information. When I did this however it seemed to work correctly the first time through. This is running a custom kernel with a custom Buildroot configuration. I don't know if there could be some kernel or iptables package misconfiguration, or possibly a bug in the versions I am using. Any suggestions would be greatly appreciated. Thanks.
