Adding DROP rule seemingly allows mDNS traffic

Home Page Forums Network Management Firewall, Traffic Shaping and Net Balancer Adding DROP rule seemingly allows mDNS traffic

This topic contains 1 reply, has 0 voices, and was last updated by  timofey.basanov@gmail.com 1 year, 7 months ago.

Viewing 1 post (of 1 total)
  • Author
    Posts
  • #44778

    I have ETH00 and ETH01 bridged into BRIDGE00 configured on ZeroShell 3.7.1 (build from Jan 2017?).
    I’m trying to allow ETH00 to access ETH01 devices, but prevent the reverse (no connection could be initiated from ETH01 interface).
    Specifically: Apple TV on ETH00 should not be visible to a laptop on ETH01.

    I set FORWARD chain to DROP. And looks like it stops all the traffic between ETH00 and ETH01.
    I add one (the only) drop rule:

    DROP all opt -- in * out * 0.0.0.0/0 -> 0.0.0.0/0

    Expected: no change
    Actual: mDNS traffic is now passing through

    More technical details:
    I use Wireshark to capture all multicast UDP traffic on 5353 on a laptop w/ IP 192.168.0.19.
    I issue a mDNS query on a laptop:

    dns-sd -L 'Apple TV'  _airplay local

    Expected (when no DROP rule is present):


    1 0.000000 192.168.0.19 224.0.0.251 MDNS 88 Standard query 0x0000 SRV Apple TV._airplay._tcp.local, "QU" question
    2 0.000021 fe80::1c7e:7f98:d97f:5dcc ff02::fb MDNS 108 Standard query 0x0000 SRV Apple TV._airplay._tcp.local, "QU" question

    Actual (after I add DROP rule):


    4 5.798594 192.168.0.19 224.0.0.251 MDNS 88 Standard query 0x0000 SRV Apple TV._airplay._tcp.local, "QM" question
    5 5.798620 fe80::1c7e:7f98:d97f:5dcc ff02::fb MDNS 108 Standard query 0x0000 SRV Apple TV._airplay._tcp.local, "QM" question
    6 5.816385 fe80::1896:9cdf:5b16:586e ff02::fb MDNS 244 Standard query response 0x0000 SRV, cache flush 0 0 7000 Apple-TV.local AAAA, cache flush fe80::1896:9cdf:5b16:586e A, cache flush 192.168.0.15 AAAA, cache flush 2602:30a:c7d4:c2d8:80d:3af:fd8d:a6de NSEC, cache flush Apple-TV.local NSEC, cache flush Apple TV._airplay._tcp.local

    Where (192.168.0.15) at c8:69:cd:3b:94:a2 is Apple TV address.

    It looks like the problem is more generic and multicast and/or ipv6 does not play well with ZeroShell firewall, but that’s the best reproducible scenario I came up with.

    And here are my iptables, just in case:


    -P INPUT ACCEPT
    -P FORWARD DROP
    -P OUTPUT ACCEPT
    -N NetBalancer
    -N SYS_DNS
    -N SYS_GUI
    -N SYS_HTTPS
    -N SYS_INPUT
    -N SYS_OUTPUT
    -N SYS_SSH
    -A INPUT -j SYS_GUI
    -A INPUT -j SYS_INPUT
    -A INPUT -p tcp -m tcp --dport 80 -j SYS_HTTPS
    -A INPUT -p tcp -m tcp --dport 443 -j SYS_HTTPS
    -A INPUT -p tcp -m tcp --dport 22 -j SYS_SSH
    -A FORWARD -j DROP
    -A OUTPUT -j SYS_OUTPUT
    -A SYS_DNS -j DROP
    -A SYS_GUI -s 192.168.0.19/32 -p tcp -m tcp --dport 12081 -j ACCEPT
    -A SYS_HTTPS -i lo -j ACCEPT
    -A SYS_HTTPS -s 10.0.0.0/8 -j ACCEPT
    -A SYS_HTTPS -s 172.16.0.0/12 -j ACCEPT
    -A SYS_HTTPS -s 192.168.0.0/16 -j ACCEPT
    -A SYS_HTTPS -j DROP
    -A SYS_INPUT -i lo -j ACCEPT
    -A SYS_INPUT -p udp -m udp --sport 53 -m state --state ESTABLISHED -j ACCEPT
    -A SYS_INPUT -p tcp -m tcp --sport 53 -m state --state ESTABLISHED -j ACCEPT
    -A SYS_INPUT -p udp -m udp --dport 53 -j SYS_DNS
    -A SYS_INPUT -p tcp -m tcp --dport 53 -j SYS_DNS
    -A SYS_INPUT -p tcp -m tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
    -A SYS_INPUT -p tcp -m tcp --sport 8245 -m state --state ESTABLISHED -j ACCEPT
    -A SYS_INPUT -p udp -m udp --sport 123 -m state --state ESTABLISHED -j ACCEPT
    -A SYS_INPUT -j RETURN
    -A SYS_OUTPUT -o lo -j ACCEPT
    -A SYS_OUTPUT -p udp -m udp --dport 53 -j ACCEPT
    -A SYS_OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT
    -A SYS_OUTPUT -p tcp -m tcp --dport 8245 -j ACCEPT
    -A SYS_OUTPUT -p udp -m udp --dport 123 -j ACCEPT-A SYS_OUTPUT -j RETURN
    -A SYS_SSH -i lo -j ACCEPT
    -A SYS_SSH -s 192.168.0.2/32 -m physdev --physdev-in ETH00 -j ACCEPT
    -A SYS_SSH -s 192.168.0.2/32 -i BRIDGE00 -j ACCEPT
    -A SYS_SSH -j DROP

    I verified that when I add the DROP rule the only change is

    -A FORWARD -j DROP

    .

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.