You are here: Home » Topic » Why Won’t mt-daapd Work Unless It’s Open to the Internet?

Why Won’t mt-daapd Work Unless It’s Open to the Internet?

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Setup Issues Why Won’t mt-daapd Work Unless It’s Open to the Internet?

This topic contains 10 replies, has 3 voices, and was last updated by  Linux User 10 years, 6 months ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #1483

    Linux User
    Participant

    I have set up an old IBM Aptiva to serve music to Windows PC’s and a Roku SoundBridge M1000 on my home network.

    The Aptiva “server” is running Firefly/mt-daapd (v. svn-1376) on Debian Linux (v. 4.0). The PC’s are Windows XP boxes with iTunes 7. My home network is behind a Lynksys WRT54G router, which provides network address translation and an internet connection through a cable modem.

    When the iptables firewall on the Aptiva is configured to restrict inbound and outbound traffic to localhost and the local network only (see below), none of the iTunes clients nor the SoundBridge can see the mt-daapd-served music library. Interestingly, however, I have no trouble seeing the administrative web interface from any browser on the network (http://[address]:3689).

    To make the mt-daapd music library visible to iTunes and the SoundBridge, I have to open up iptables to traffic to and from the internet (see below). If I do that, no problem. The served library pops up on all the iTunes clients (sometimes I have to restart iTunes, but sometimes it just shows up) and the SoundBridge and plays with no problem.

    Oddly, if I open up the firewall so the library appears, I can close it down again once the libarary shows up and can still see the library and play music from it, for awhile anyway. After awhile, the library disappears and any music playing from it stops.

    Even though my home network is behind a router that provides some protection from the internet via NAT, I like using iptables on the Linux box to restrict traffic to the local network. (I have firewalls on all my Windows PC’s, too.)

    I have seen some info in these forums about multicasting, but I don’t see why mt-daapd should have to be able to multicast to the internet, and I didn’t see any clear guidance on configuring iptables to allow the necessary multicasting while keeping the internet out.

    So, why does mt-daapd have to be able to connect to the internet to work on a local network? What if I weren’t connected to the internet at all?! And what can I do to enable it to work while maintaining a reasonable level of security on the machine it’s running on? It’s a pretty slick setup when it’s working, but I don’t want to run the Linux box without a firewall.

    Thanks!

    ============ iptables dumps =================

    Here’s what iptables -L looks like when it’s not working. This restricts traffic to the local machine and the local network. With this set of rules, the mt-daapd music library cannot be seen by iTunes or the SoundBridge.


    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

    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

    Here’s what iptables -L looks like when it is working. This allows inbound traffic that’s in response to an outbound request (an established connection), and it allows all outbound traffic. With this set of rules, the mt-daapd library is visible to iTunes and the SoundBridge.


    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    ACCEPT 0 -- localhost.localdomain localhost.localdomain
    ACCEPT 0 -- 192.168.1.0/24 192.168.1.0/24
    DROP tcp -- anywhere anywhere tcp flags:SYN,RST,ACK/SYN
    DROP icmp -- anywhere anywhere

    Chain FORWARD (policy DROP)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    This set of rules works, too. These are like the second set above — they allow all outbound and only established inbound — but they also explicitly block access from outside the local network to some specific ports/services (not all of which are actually running on this box — I borrowed these rules from another Linux box to see if they would work).


    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    ACCEPT 0 -- localhost.localdomain localhost.localdomain
    ACCEPT 0 -- 192.168.1.0/24 192.168.1.0/24
    DROP tcp -- anywhere anywhere tcp flags:SYN,RST,ACK/SYN
    DROP tcp -- !192.168.1.0/24 anywhere tcp dpt:x11
    DROP udp -- !192.168.1.0/24 anywhere udp dpt:x11
    DROP tcp -- !192.168.1.0/24 anywhere tcp dpt:mysql
    DROP udp -- !192.168.1.0/24 anywhere udp dpt:mysql
    DROP tcp -- !192.168.1.0/24 anywhere tcp dpt:ipp
    DROP udp -- !192.168.1.0/24 anywhere udp dpt:ipp
    DROP tcp -- !192.168.1.0/24 anywhere tcp dpt:https
    DROP udp -- !192.168.1.0/24 anywhere udp dpt:https
    DROP tcp -- !192.168.1.0/24 anywhere tcp dpt:sunrpc
    DROP udp -- !192.168.1.0/24 anywhere udp dpt:sunrpc
    DROP tcp -- !192.168.1.0/24 anywhere tcp dpt:www
    DROP udp -- !192.168.1.0/24 anywhere udp dpt:www
    DROP tcp -- !192.168.1.0/24 anywhere tcp dpt:smtp
    DROP udp -- !192.168.1.0/24 anywhere udp dpt:25

    Chain FORWARD (policy DROP)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    #11205

    fizze
    Participant

    Your rules block out multicasts / unicasts. That’s why firefly’s share can’t be seen by any client then. πŸ˜‰

    #11206

    rpedde
    Participant

    @fizze wrote:

    Your rules block out multicasts / unicasts. That’s why firefly’s share can’t be seen by any client then. πŸ˜‰

    What fizze said. You need to allow traffic to/from 224.0.0.0/4, that’s the multicast network.

    Or you can slim it down to just 224.0.0.251, as thats the only multicast address mdns uses, but you’ll run into problem later with other multicast apps unless you unfirewall the whole class d range now.

    — Ron

    #11207

    Linux User
    Participant

    Thanks Ron and fizze.

    I tried adding the following rules (separately, in the pairs shown), but none of them worked:


    iptables -A INPUT -s 224.0.0.0/4 -d 127.0.0.1 -j ACCEPT
    iptables -A OUTPUT -s 127.0.0.1 -d 224.0.0.0/4 -j ACCEPT

    iptables -A INPUT -s 224.0.0.0/4 -d 192.168.1.0/24 -j ACCEPT
    iptables -A OUTPUT -s 192.168.1.0/24 -d 224.0.0.0/4 -j ACCEPT

    iptables -A INPUT -s 224.0.0.0/4 -d 224.0.0.0/4 -j ACCEPT
    iptables -A OUTPUT -s 224.0.0.0/4 -d 224.0.0.0/4 -j ACCEPT

    So, then I tried the following, which allows multi/unicast packets specifically, but without restriction as to source or destination addresses:


    iptables -A INPUT -m pkttype --pkt-type multicast -j ACCEPT
    iptables -A OUTPUT -m pkttype --pkt-type multicast -j ACCEPT
    iptables -A INPUT -m pkttype --pkt-type unicast -j ACCEPT
    iptables -A OUTPUT -m pkttype --pkt-type unicast -j ACCEPT

    Now THAT worked. But it allows sending and receiving multi/unicasts to the public internet doesn’t it? Am I advertising my music library to the public internet? ‘Cause I don’t want to be doing that.

    Why does firefly have to be able to multi/unicasts without limit on source or destination? What it is about firefly and/or multi/unicasting that I don’t get?

    Ron, I’m new to firefly and the SoundBridge, so forgive my ignorance, but I just saw over on the Roku forums that you’re the author of firefly. Let me just say what a cool app it is. Setting up a central server to serve my music files to various places in my house has been on my project list for a long time, and firefly plus the SoundBridge is a pretty slick solution.

    Thanks.

    #11208

    rpedde
    Participant

    @Linux User wrote:

    Thanks Ron and fizze.

    I tried adding the following rules (separately, in the pairs shown), but none of them worked:


    iptables -A INPUT -s 224.0.0.0/4 -d 127.0.0.1 -j ACCEPT
    iptables -A OUTPUT -s 127.0.0.1 -d 224.0.0.0/4 -j ACCEPT

    iptables -A INPUT -s 224.0.0.0/4 -d 192.168.1.0/24 -j ACCEPT
    iptables -A OUTPUT -s 192.168.1.0/24 -d 224.0.0.0/4 -j ACCEPT

    iptables -A INPUT -s 224.0.0.0/4 -d 224.0.0.0/4 -j ACCEPT
    iptables -A OUTPUT -s 224.0.0.0/4 -d 224.0.0.0/4 -j ACCEPT

    True. The rules should probably be:

    iptables -A INPUT -s 224.0.0.0/4 -j ACCEPT
    iptables -A OUTPUT -d 224.0.0.0/4 -j ACCEPT

    When it sends multicast, it uses the addressable interface, not the loopback. Probably a 192.168 address.

    So there is clearly some misconception about multicast. Here’s the 30 second multicast primer. Imagine the case where you are streaming live video. You can have everyone connect to your server, and each download the data on individual connections. But that sucks, because you are using tons of bandwidth to stream video, when all of it is the same content. A better solution would be to send out one copy of the data to everyone that was interested in seeing it. It would be a hard problem, because you’d have to send it to every connected router that had someone who was interested in watching the video behind it. And so on, through every router connected between you and all the users who wanted to see it.

    But that’s what multicast does. To make it work, they took all the class “d” addresses and made them multicast addresses. These addresses are really collections of computers that have “joined” that address (or multicast group). So for example, I could have my video running on a specific multicast address, spewing out video constantly. When someone wanted to see it, they could join that multicast address, and suddenly the traffic that I was sending to that multicast address would appear at the end station.

    Course, it’s more complex than that… all the routers in between have to notify each other about multicast subscriptions and stuff, but essentially that’s it. Multicast is really kind of a “channel” that interested computers can “join” and receive data. Kind of a network inside the network, connected by multicast enabled routers.

    I’m not doing this justice, but the point is that multicast groups look like ip addresses in the 224 range, but are really nothing more than quieter broadcast than broadcast. If that makes sense.


    iptables -A INPUT -m pkttype --pkt-type multicast -j ACCEPT
    iptables -A OUTPUT -m pkttype --pkt-type multicast -j ACCEPT
    iptables -A INPUT -m pkttype --pkt-type unicast -j ACCEPT
    iptables -A OUTPUT -m pkttype --pkt-type unicast -j ACCEPT

    Now THAT worked. But it allows sending and receiving multi/unicasts to the public internet doesn’t it? Am I advertising my music library to the public internet? ‘Cause I don’t want to be doing that.

    You don’t want that. First, you won’t be advertising. No routers enable multicast by default, so the multicast packets are getting dropped at your gateway router to the net.

    Secondly, you don’t want to allow unicast. Unicast is all traffic that isn’t multicast or broadcast, which is pretty much all traffic you want to block — web traffic, mail traffic, pretty much everything tcp. You don’t want that.

    Why does firefly have to be able to multi/unicasts without limit on source or destination?

    That’s the nature of multicast, and that’s what it uses to locate servers on the network. It’s a better way than broadcast, as it doesn’t spam packets to machines that aren’t interested.

    is there some kind of spyware in there, is it reporting back to HQ?

    Spyware? that’s why it’s source available. πŸ˜‰

    What it is about firefly and/or multi/unicasting that I don’t get?

    Multicast is kinda wierd. these guys probably explain it better. πŸ™‚

    #11209

    Linux User
    Participant

    Thanks, Ron, for the clear, informative and detailed explanation. Very helpful, and reasurring.

    I tried the two rules you suggested. Not sure why, but they didn’t work.

    So, then, based on your recommendation not to allow unicast, I tried just the multicast packet rules I’d used before. Guess what? Didn’t work. But when I put the unicast packet rules back in, it popped right up.

    So, just for kicks, I tried just the unicast packet rules. Didn’t work either. Oddly, it only works if I allow both multicast and unicast packets.

    Then I decided to combine my packet rules with your suggested rules, on the perhaps misguided assumption that some source and destination address limits were better than none, thusly:

    iptables -A INPUT -s 224.0.0.0/4 -m pkttype --pkt-type multicast -j ACCEPT
    iptables -A OUTPUT -d 224.0.0.0/4 -m pkttype --pkt-type multicast -j ACCEPT
    iptables -A INPUT -s 224.0.0.0/4 -m pkttype --pkt-type unicast -j ACCEPT
    iptables -A OUTPUT -d 224.0.0.0/4 -m pkttype --pkt-type unicast -j ACCEPT

    That didn’t work, either.

    So for the moment, the only thing that works is allowing both multicast and unicast packets without restriction as to source or destination address. I’m a little concerned about that, because you said I don’t want to open up to unicasts.

    Btw, all this recent testing is with the iTunes client. Haven’t checked anything other than what was in my original post with the SoundBridge. But I need to get it working with both, so even if any of this worked only with the SoundBridge, that would be interesting but not quite where I need to be.

    Also, btw, the spyware reference was a joke, so I hope you didn’t take offense, none was intended. (I’m new to this and I just saw over at the Roku forum that you’re the author of firefly.) It’s a great app and provides a solution to a project I’ve been working on for a long time, especially when combined with the SoundBridge. If I can just kick this firewall thing. And, yes, while I doubt I could understand the source code if I read it, just knowing it’s out there is a good thing! πŸ™‚

    Thanks for your help.

    #11210

    rpedde
    Participant

    @Linux User wrote:

    Thanks, Ron, for the clear, informative and detailed explanation. Very helpful, and reasurring.

    I tried the two rules you suggested. Not sure why, but they didn’t work.

    k. Here’s a tip to log your drops…

    at the end of your iptables script, you likely have something like:

    iptables -A INPUT -j DROP

    or

    iptables -A OUTPUT -j DROP

    Either that, or you just set default policy to drop, then let it drop off the end of the table list.

    You can do something like this at the end of script:

    /sbin/iptables -N LOGDROP
    /sbin/iptables -A LOGDROP -j LOG
    /sbin/iptables -A LOGDROP -j DROP

    /sbin/iptables -A INPUT -j LOGDROP
    /sbin/iptables -A OUTPUT -j LOGDROP

    Then, rather than dropping to the default “DROP” rule, any packets that *would* have been dropped instead get logged then dropped. Then you can check your syslog and see what’s being dropped. Then you can see what source addr, dest addr, etc are, and fix your rules.

    If you don’t want the syslog traffic, you can keep those normally commented out, and just add them when you want/need the extra logging.

    — Ron

    #11211

    Linux User
    Participant

    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.

    #11212

    josephwinston

    I have the same problem on ubuntu feisty. At startup:


    # iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    I used:


    # iptables -A INPUT -s 192.168.2.0/24 -d 224.0.0.0/4 -j ACCEPT
    # iptables -A INPUT -s 192.168.2.0/24 -d 255.255.255.255 -j ACCEPT
    # iptables -A OUTPUT -s 192.168.2.0/24 -d 224.0.0.0/4 -j ACCEPT
    # iptables -A OUTPUT -s 192.168.2.0/24 -d 255.255.255.255 -j ACCEPT

    Giving:


    # iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    ACCEPT 0 -- 192.168.2.0/24 BASE-ADDRESS.MCAST.NET/4
    ACCEPT 0 -- 192.168.2.0/24 255.255.255.255

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    ACCEPT 0 -- 192.168.2.0/24 BASE-ADDRESS.MCAST.NET/4
    ACCEPT 0 -- 192.168.2.0/24 255.255.255.255

    But no joy. What am I missing? Or how do I parse the spew from the logging?

    #11213

    rpedde
    Participant

    @josephwinston wrote:

    I have the same problem on ubuntu feisty. At startup:


    # iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    I used:


    # iptables -A INPUT -s 192.168.2.0/24 -d 224.0.0.0/4 -j ACCEPT
    # iptables -A INPUT -s 192.168.2.0/24 -d 255.255.255.255 -j ACCEPT
    # iptables -A OUTPUT -s 192.168.2.0/24 -d 224.0.0.0/4 -j ACCEPT
    # iptables -A OUTPUT -s 192.168.2.0/24 -d 255.255.255.255 -j ACCEPT

    Giving:


    # iptables -L
    Chain INPUT (policy ACCEPT)
    target prot opt source destination
    ACCEPT 0 -- 192.168.2.0/24 BASE-ADDRESS.MCAST.NET/4
    ACCEPT 0 -- 192.168.2.0/24 255.255.255.255

    Chain FORWARD (policy ACCEPT)
    target prot opt source destination

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination
    ACCEPT 0 -- 192.168.2.0/24 BASE-ADDRESS.MCAST.NET/4
    ACCEPT 0 -- 192.168.2.0/24 255.255.255.255

    But no joy. What am I missing? Or how do I parse the spew from the logging?

    I think what we’ve decided on feisty (after troubleshooting on a bunch of threads) is that the edgy package from universe doesn’t work right on feisty. I’m going to drop a nightlies hopefully tomorrow built specifically for feisty, and we’ll see if that works better.

    — Ron

    #11214

    Linux User
    Participant

    josephwinston, whatever your problem is, it’s not the firewall.

    As your default polices are all ACCEPT and you have no DROP rules, your firewall is allowing all traffic through in all directions. The two rules you added don’t make a difference. They’re just allowing traffic that the default rules would have allowed anyway.

    If you want to make the firewall useful, you should either (a) change the default policies to DROP and then add rules to just allow the traffic you want to allow, or (b) if you leave the default policies as ALLOW, at least add some DROP rules to protect against malicious traffic (e.g., block external traffic to certain services, like X11). Of the two approaches, option (a) is more secure but may take more work to figure out what traffic you need to allow to make things work, vis. my struggle above. While option (b) is better than nothing, there’s always the risk that you’ve overlooked closing off something that should be closed off.

Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.