Fw4 ignores 'include' option

axet · June 26, 2022, 5:43pm

Hello!

Just moved from 21.02 to 22.03 and findout that my old scripts from /etc/config/firewall do not load new updated ntf include scripts. I tried few things: chmod +x /etc/firewall.lan2wan and adding #!/bin/bash to the begining of script - nothing makes to apply new rules.

Script file has been converted to 'ntf'. Scripts was working with 21.02. Scripts works if run manually from bash. Looks like a bug. Firefwall 'include' option no longer works!

RuralRoots · June 26, 2022, 6:31pm

From the 22.03 Release Announcement:
The extra option which allowed to add custom iptables commands does not work any more.

/etc/firewall.user

Is no more. Search the forums.

axet · June 26, 2022, 6:45pm

I guess wiki should be updated:

https://openwrt.org/docs/guide-user/firewall/firewall_configuration

dave14305 · June 26, 2022, 7:36pm

New include syntax:

github.com/openwrt/openwrt

firewall4: design shortcomings in fw4 custom filter chains

opened 11:43AM - 02 Jun 22 UTC

Shine-

core packages

### Problem description: fw4 custom filter chains ("10-custom-filter-chains.n…ft" or "*.nft") have some logic/design issues. Below are two example cases, and I'm sure there are more. ### Case 1: Background: Firewall rules should always be processed from top to bottom. If one rule is matched, processing should end, so the matched rule can come into effect. This works fine as long as you remain within **only one nft chain**. As soon as you add additional chains, nft behaves differently. A "Drop" rule in any chain will render all "Allow" rules in all previous (lower priority) chains void. This is due to nft's behavior of continuing to process any later chains, even if a rule matches, **until** a Drop is found. So the "top to bottom" approach suddenly applies only to "Drop" rules, not to "Allow" rules anymore. Consequently, this renders fw4's "*.nft" files - which can add additional chains, but not any additional rules in the default chain - quite useless, because they can only be used for "Drop" rules, not for "Allow" rules. ### Problem for Case 1: Due to the nft behavior with multiple chains, at this time, the user doesn't have a possibility to add custom "Allow" rules to fw4. This especially prohibits the user from configuring fw4 like a proper network firewall should be configured: Deny everything unless explicitly allowed - since the "Deny all" last rule will override any previous "Allow" rules from any lower priority chains! ### Case 2: Background: In a stateful firewall, flows that are already handled by a firewall rule should not be sent through the whole rulebase processing again, as this would mean wasting CPU cycles and therefore slowing down firewall performance. This works fine, as long as the default fw4 chains are the **only** chains used. These chains contain an "Accept" rule for "established,related". As soon as the user adds additional chains (without own "established,related" rules), these complete chains are processed for every packet. As already described in Case 1, this re-processing will repeat for each and every chain, as an "Accept" rule will not stop processing later chains. ### Problem for Case 2: By adding simple additional rules as separate nft chains, instead of within the default chains, performance will suffer. ### Suggestion: "*.nft" files aren't currently useful for the purpose one would suppose: quickly adding additional firewall rules that aren't supported in uci/LuCI syntax. While Case 2 is just "inconvenient", but can be solved by adding "established,related" rules to each chain, I don't see how Case 1 can be solved in the current state of fw4 at all. The possibility of adding complete additional nft chains might be useful for special purposes. It is, however, not a feasible way of quickly adding custom firewall rules. Therefore, it should not be the **only** possible way of customizing the fw4 ruleset. Rather, the user should be given an easy possibility of customizing the fw4 default chains, without having to think of all side effects and limits that he might have when using separate nft chains. After all, the standard OpenWRT user, or even the OpenWRT Power User, is not a nft expert!

system · July 6, 2022, 7:36pm

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