iptables help

[mattbo]

Hi all,

I’m working on getting firefly going with OpenWRT on a Linksys WRTSL54GS (router with usb port) and an SB 1001. I’m 99.9% there 🙂

I’m running mt-daapd (svn-1463) with mDNSResponder (howl 1.0.0), and it works ok. My trouble is with iptables. If I set all the rules to ACCEPT, then the SB can see the mt-daapd. However, I like having a firewall. So can someone help me figure out reasonable rules to get things working?

Output from iptables -L after I mucked about for several hours:

Chain INPUT (policy DROP)

target     prot opt source               destination

DROP       all  --  anywhere             anywhere            state INVALID

ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED

DROP       tcp  --  anywhere             anywhere            tcp option=!2 flags:SYN/SYN

input_rule  all  --  anywhere             anywhere

LAN_ACCEPT  all  --  anywhere             anywhere

ACCEPT     icmp --  anywhere             anywhere

ACCEPT     gre  --  anywhere             anywhere

REJECT     tcp  --  anywhere             anywhere            reject-with tcp-reset

REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable



Chain FORWARD (policy DROP)

target     prot opt source               destination

DROP       all  --  anywhere             anywhere            state INVALID

TCPMSS     tcp  --  anywhere             anywhere            tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU

ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED

forwarding_rule  all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere



Chain OUTPUT (policy DROP)

target     prot opt source               destination

DROP       all  --  anywhere             anywhere            state INVALID

ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED

output_rule  all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere

REJECT     tcp  --  anywhere             anywhere            reject-with tcp-reset

REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable



Chain LAN_ACCEPT (1 references)

target     prot opt source               destination

RETURN     all  --  anywhere             anywhere

ACCEPT     all  --  anywhere             anywhere



Chain forward_eth1 (1 references)

target     prot opt source               destination



Chain forwarding_rule (1 references)

target     prot opt source               destination

forward_eth1  all  --  anywhere             anywhere



Chain input_eth1 (1 references)

target     prot opt source               destination



Chain input_rule (1 references)

target     prot opt source               destination

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:3689

ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:5353

input_eth1  all  --  anywhere             anywhere



Chain output_rule (1 references)

target     prot opt source               destination

ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:5353

( eth1 is WAN and eth0 is LAN. I’d like music available on the LAN only.).

If someone can help me, I promise to add a wiki page for firefly on OpenWRT !

Thanks,
Matt

[rpedde]

@mattbo wrote:

I’m running mt-daapd (svn-1463) with mDNSResponder (howl 1.0.0), and it works ok. My trouble is with iptables. If I set all the rules to ACCEPT, then the SB can see the mt-daapd. However, I like having a firewall. So can someone help me figure out reasonable rules to get things working?

These look reasonable, so I’m not sure where it’s broken.

If you don’t see it though, then it’s probably on the output chain. That’s where it pushes an announcement and it pops into iTunes. So if you can start iTunes, then start the mt-daapd server and it doesn’t show up in iTunes, then it’s the output chain.

You could try a couple things.

1. Set the output chain to accept all, then look at the packet with a sniffer… maybe it’s not *to* port 5353, but *from* port 5353. Or vice versa. Whatever.

2. Add a log rule before the rejects so you can see what’s being dropped… then you can see why.

Another thing to try would be to allow each chain in turn — one at a time. That way you can find out which chain is causing the problem.

I don’t have a specific answer for you, but those are the troubleshooting ideas I have. Not sure if that helps, but I hope so.

— Ron

[mattbo]

I’ll try it and get back to you later tonight. Alas, (paid) work calls for now :).

Ports 5353 UDP and 3689 TCP both need to be open in both directions ?

I think the current setup works with iTunes 7, just not with the SB, but I’ll double check.

Thanks!
-Matt

[rpedde]

@mattbo wrote:

I’ll try it and get back to you later tonight. Alas, (paid) work calls for now :).

Ports 5353 UDP and 3689 TCP both need to be open in both directions ?

I think the current setup works with iTunes 7, just not with the SB, but I’ll double check.

Thanks!
-Matt

mt-daapd receives incoming 3689 tcp. That’s it.

The mdns responder receives mdns queries destined to 224.0.0.251 to port 5353.

It sends traffic out, but I’m not sure what that looks like. Might be unicast, I’m not sure. But it will be from udb port 5353.

Obviously that isn’t correct, though, because it appears that your rules are already set up that way. So my understanding is somehow flawed.

— Ron

[mattbo]

Excellent suggestion to divide and conquer.

I cleared the input chain and set the policy to accept, and the SB can now see Firefly. I’m still mucking around trying to figure out exactly which rule is hosing things.

Interestingly, browsing only works if I clear the output chain as well. So apparently there are two issues to deal with.

More to come as I figure things out.

Matt

[rpedde]

@mattbo wrote:

I cleared the input chain and set the policy to accept, and the SB can now see Firefly. I’m still mucking around trying to figure out exactly which rule is hosing things.

Note that could be a red herring. Even if the mdns reponder doens’t get mdns queries (which would break mdns resolving), when the service starts, it spams out mdns announcements for pre-caching. So starting the mt-daapd server (if the outbound mdns works) will populate the mdns browse lists of clients even if mdns isn’t totally working.

You’ll know you have a “mdns server not recieving mdns queries” problem if it periodically drops off (server not available, or disappears from iTunes browse) after 10 minutes or so.

— Ron

[Author]

Posts