You are here: Home » Topic » iptables help

iptables help

This topic contains 5 replies, has 2 voices, and was last updated by  rpedde 10 years, 7 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #928

    mattbo
    Participant

    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

    #8133

    rpedde
    Participant

    @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

    #8134

    mattbo
    Participant

    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

    #8135

    rpedde
    Participant

    @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

    #8136

    mattbo
    Participant

    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

    #8137

    rpedde
    Participant

    @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

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

You must be logged in to reply to this topic.