Oh, brilliant idea. And it worked! 😀
The syslog revealed that the firewall as originally configured was blocking not only the multicast packets but also the broadcast packets on 255.255.255.255. You were on the right track when you suggested adding rules to allow multicasting, but it turned out I had to enable broadcasting as well. The only way I figured that out was by checking the syslog.
It took careful inspection of the syslog and some trial and error, but here is my final iptables configuration. The third and fourth rules in the INPUT and OUTPUT chains are what I had to add to make it work. Note that the source addresses are the same for the INPUT and OUTPUT chains, rather being swapped with the destination address for the different chains, which is what I had originally expected they would have to be.
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT 0 -- localhost.localdomain localhost.localdomain
ACCEPT 0 -- 192.168.1.0/24 192.168.1.0/24
ACCEPT 0 -- 192.168.1.0/24 224.0.0.0/4 <== This is the multicasting rule
ACCEPT 0 -- 192.168.1.0/24 255.255.255.255 <== This is the broadcasting rule
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT 0 -- localhost.localdomain localhost.localdomain
ACCEPT 0 -- 192.168.1.0/24 192.168.1.0/24
ACCEPT 0 -- 192.168.1.0/24 224.0.0.0/4 <== This is the multicasting rule
ACCEPT 0 -- 192.168.1.0/24 255.255.255.255 <== This is the broadcasting rule
I think this is a better solution than the packet rules I had previously tried (and posted) because the packet rules didn’t restrict traffic to just the local network. Also, they allowed unicasting, which you said was a bad (or at least insecure) thing. This article http://www.comptechdoc.org/independent/networking/guide/netbroadcasting.html indicates that most routers in their default configuration don’t allow packets broadcast on 255.255.255.255 out to the internet, and I think you had said the same thing about multicast packets, so the restriction to the local network (192.168.1.0/24) may be overkill, but what the hey, it doesn’t hurt (ok, it made the solution a little harder to figure out) and it might help.
So, the short answer to the question posed by the title of this thread is that firefly/mt-daapd does not have to be exposed to the internet to work. But, both multicasting and broadcasting on the local network have to be enabled.
Thoughts?
Thanks for all your help. Again, great app.
Cheers.