Firewall: unexpected allowed port

Installing and Using OpenWrt
1

I have 24.10.0 installed on an ER-X with a couple of VLANs for various networks. Some of the networks are isolated (like IOT), but since the ER-X is the DNS server for all the networks I added a wildcard rule for port 53 to the firewall. I don't however want DNS accessible from the WAN, so I prepended a rule to drop port 53 traffic from wan.

This does not behave as I intended, and leaves port 53 open for ingress from the wan.

Here are the relevant lines from my /etc/config/firewall:

config zone
        option name 'wan'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option input 'DROP'
        list network 'ftth'
        list network 'ftth6'
...
config rule
        option name 'Disallow WAN DNS'
        option src 'wan'
        option dest_port '53'
        option target 'DROP'
...
config rule
        option name 'Allow DNS'
        option src '*'
        option dest_port '53'
        option target 'ACCEPT'

This seems to result in an ACCEPT rule in the 'input' chain, which presumably precedes the 'input_wan' chain.

fw4 print:

table inet fw4
flush table inet fw4
delete flowtable inet fw4 ft

table inet fw4 {
...
        chain input {
                type filter hook input priority filter; policy accept;

                iif "lo" accept comment "!fw4: Accept traffic from loopback"

                ct state vmap { established : accept, related : accept } comment "!fw4: Handle inbound flows"
                tcp flags & (fin | syn | rst | ack) == syn jump syn_flood comment "!fw4: Rate limit TCP syn packets"
                tcp dport 53 counter accept comment "!fw4: Allow DNS"
                udp dport 53 counter accept comment "!fw4: Allow DNS"
                ip daddr 224.0.0.251 udp dport 5353 counter accept comment "!fw4: Allow mDNS"
                udp dport 67 counter accept comment "!fw4: Allow DHCP"
                meta l4proto { "icmp", "ipv6-icmp" } counter accept comment "!fw4: Allow inbound ICMP"
                iifname "br-lan.99" jump input_lan comment "!fw4: Handle lan IPv4/IPv6 input traffic"
                iifname "pppoe-ftth" jump input_wan comment "!fw4: Handle wan IPv4/IPv6 input traffic"
...
        }
...
        chain input_wan {
...
                tcp dport 53 counter drop comment "!fw4: Disallow WAN DNS"
                udp dport 53 counter drop comment "!fw4: Disallow WAN DNS"
...
                jump drop_from_wan
        }

I don't think this is any different from the behaviour under 23.05. I also know that I can exclude the 'wan' zone from DNS service, and I have, although that results in rejects rather than drops.

I realise that I can work around this by enumerating all the allowed zones in the allow rule, rather than using a pair of 'deny one'/'allow wildcard' rules. Aside from being a little more verbose and prone to error, that would be fine.
However I was somehow under the impression that earlier rules would take precedence over later rules, so this behaviour caught me by surprise.
Is this working as intended or is it a bug?

2

This behavior is completely expected.

As you can see, regardless of the order of the rules, option src '*' always takes precedence over option src 'some_zone'.

If you insist on this approach, here is another possible workaround (based on the posted fw4 print output).

config rule
        option name 'Disallow WAN DNS'
        option src '*'
	    option device 'pppoe*'
        option dest_port '53'
        option target 'DROP'

config rule
        option name 'Allow DNS'
        option src '*'
        option dest_port '53'
        option target 'ACCEPT'
2 Likes
3

Thanks! This worked like a charm.

config rule
        option name 'Disallow WAN DNS'
        option src '*'
	    option device 'pppoe*'
        option dest_port '53'
        option target 'DROP'

config rule
        option name 'Allow DNS'
        option src '*'
        option dest_port '53'
        option target 'ACCEPT'
4

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.