Previous rules for NAS access not working possibly after recent fw4 changes

Installing and Using OpenWrt Network and Wireless Configuration
1

The rules used to work flawlessly, but not so after upgraded to snapshot r20956-6893dd4803, which has included latest fw4 changes/upgrades.

Reload firewall rules give me the following warnings:

root@OpenWrt:~# /etc/init.d/firewall reload
Section @rule[9] (Support-UDP-Traceroute) is disabled, ignoring section
Section @include[0] is not marked as compatible with fw4, ignoring section
Section @include[0] requires 'option fw4_compatible 1' to be considered compatible

It might be causing my rules not working. May I ask how do I suppose to address this 'breaking' issue?

And just checked with 'nft list ruleset' and found the rules are actually in the right place, it just not working anymore.

BTW, my rules is like:

config rule
        option name 'Allow Samba Access'
        list dest_ip '192.168.1.3'
        list dest_ip '192.168.1.7'
        option dest_port '445'
        option target 'ACCEPT'
        list src_mac '00:xx:xx:xx:xx:xF'
        option src 'guest'
        option dest 'lan1'
        option device 'wlan0'

Edit2: About the warning, I just found it's nothing related to the issue at all.

Edit3: The corresponding nft rule listed as:

        chain forward_guest {
                iifname "wlan0" ip daddr { 192.168.1.3, 192.168.1.7 } tcp dport 445 ether saddr 00:xx:xx:xx:xx:xf counter packets 0 bytes 0 jump accept_to_lan1 comment "!fw4: Allow Samba Access"
                iifname "wlan0" ip daddr { 192.168.1.3, 192.168.1.7 } udp dport 445 ether saddr 00:xx:xx:xx:xx:xf counter packets 0 bytes 0 jump accept_to_lan1 comment "!fw4: Allow Samba Access"
                ip daddr { 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 172.16.0.0/12, 192.0.0.0/24, 192.0.2.0/24, 198.18.0.0/15, 198.51.100.0/24, 203.0.113.0/24, 224.0.0.0-255.255.255.255 } counter packets 0 bytes 0 jump reject_to_lan1 comment "!fw4: Block guest -> private network"
                jump accept_to_lan1 comment "!fw4: Accept guest to lan1 forwarding"
                jump reject_to_guest
        }
2

Updates as follow, just in case others encountered similar problems.

It turned out the incompatibility of 'include' indeed is the culprit, the issue gone after I comment the following rules in /etc/config/firewall

#config include
#       option path '/etc/firewall.user'

Edit: Sorry that I was jumping into conclusions too fast, the access of NAS is still blocked.

3

The following rules are behind the NAS rule:

config rule
        option name 'Block guest -> private network'
        list proto 'all'
        option src 'guest'
        option dest 'lan1'
        list dest_ip '0.0.0.0/8'
        list dest_ip '10.0.0.0/8'
        list dest_ip '127.0.0.0/8'
        list dest_ip '169.254.0.0/16'
        list dest_ip '172.16.0.0/12'
        list dest_ip '192.0.0.0/24'
        list dest_ip '192.0.2.0/24'
        list dest_ip '224.0.0.0/3'
        list dest_ip '192.168.0.0/16'
        list dest_ip '198.18.0.0/15'
        list dest_ip '198.51.100.0/24'
        list dest_ip '203.0.113.0/24'
        option target 'REJECT'

Here's the thing, if the list dest_ip '192.168.0.0/16' was commented out, I can access to the NAS which is on 192.168.1.0/24 subsection. The same rules used to work as expected.

Edit: Now question is, how can I get the same result as before, i.e., making NAS access an exception of Block guest -> private network instead of sacrificing the blocking for maximizing safety.

4

I have a feeling one of your custom rules probably override the UCI one.

You could simply put the guest network in a separate firewall zone; and then you wouldn't need these elaborate rules. The zone rules will block guest devices from accessing other networks (when set properly - e.g. on initial setup, the guest zone will be configured to not allow traffic).

5

If the more specific rule is above the more general rule, then the packet will be allowed if it matches the conditions of the allow rule.

1 Like
6

Thanks for the tip.

By eliminating condition that can cause the un-match one by one, eventually I found that it's the device name has changed from wlan0 to phy0-ap0. Surely this has nothing to do with fw4.

@All, thank you so much for your concerning and suggestions.

7

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