- This topic has 10 replies, 4 voices, and was last updated 16 years, 10 months ago by
.
-
Posts
-
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
Your rules block out multicasts / unicasts. That’s why firefly’s share can’t be seen by any client then. 😉
@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
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.
@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 ACCEPTWhen 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. 🙂
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.
@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 LOGDROPThen, 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
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.
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?
@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
- The forum ‘Setup Issues’ is closed to new topics and replies.