One firewall configuration change a user might want, which should be the simplest, is to implement an Internet Death Penalty against an annoying set of IPs. OpenWRT at present makes this a bit complicated, as to do it you need to add four traffic rules and two "ip sets" pointed at a common include file.
It is four rules because to truly make your own IP a "hole in space" to those you shun, you need separate rules for input and output, and also separate rules to cover traffic to the OpenWRT device itself, and for forwarding. 2 times 2 is four.
Two UI improvements would help:
Add a "Reciprocal Action" property under "Action" in General Settings for a rule. It could be set "none" to have the present behaviour, or any value valid for "Action", in which case the system would first generate a rule in the underlying ACLs as if the field was not present, and then generate a second rule with the "Reciprocal Action" used in place of "Action", and the Source Zone and Addresses flipped with the Destination Zone and Addresses. The interpretation of any attached IP Set as source or destination must also be toggled (which is something that can't be explicitly requested at present, hence the current need for doubled IP sets).
In the "Source Zone" and "Destination Zone" fields, there should be an "Any Zone or Device" option that causes both "Device" rule(s) and "Any Zone" rules(s) to be generated.
With these features, an IDP would be best done by setting the Source Zone to the WAN, the Destination Zone to "Any Zone Or Device", the Source Address or IPSet to the shunned addresses, Action to Drop, and Reciprocal Action to Reject.
Hard to understand what you are trying to do (sure you dont want to kill the internet)
1/ stateful firewall nftables needs connections permitted only in 1st direction, other direction works automatically
2/ depends on rule type, certainly any zone is permitted for connections towards router itself and their replies as per /1/
IDP oddly isn't described on Wikipedia, but it is longstanding internet jargon extant in the 90s. It means to configure a router to boycott all traffic from/to an internet entity you are shunning, so whatever the victim is paying his ISP (or in extreme cases, a rogue ISP is paying a backbone) no longer buys access to you. It's a weak "denial of service" that is entirely legal since it is your own "service" that you are withholding.
Additionally, should I "accidentally" try to connect to a shunned IP, say because unknown to me a website is hosted on the same IP as a scanner that tried to harass me, I want a clean rejection before any packet leaves my network. I don't see how statefulness could do this for me based just on input rules, because it's outgoing TCP SYN or UDP packets that need to be stopped.
While the user interface isn't entirely clear on this, my belief that doubled rules are indeed currently necessary to cover both "WAN to LAN" and "WAN to Device" is because I can see both rules in the "Status / Firewall" LuCI page, and they have separate hit counts. It can't be the system already duplicating the “Any Zone” rule and then optimizing the filter chain so the redundancy is invisible, because if I create a third IP Set (pointing at the same include file) and switch one of the UI rules to it, I see no reference to the forward ipset in the input chain or vice versa.
Usenet Death Penalty is something different. That refers to censorship in the “Application Layer”, specific to the NNTP protocol (and back in the day, the UUCP version of Usenet that preceded it.) UDPs can be quite damaging because they only happen when a large group of Usenet entities have agreed on it. They also come in an active mode, which would be clear abuse of the net if it wasn’t pre-agreed by the largest parties in Usenet.
Internet Death Penalty is at the network layer and always passive.
So you talking about balcklists/blocklists which are typically implemented by banip, bcp38, blackhole routes. Depending on your need also consider DNS filtering like various advertisment blockers.
I get more and more the feeling that new users just post the output of some chat bot session here.
As @brada4 said, the Internet has changes a lot since the last 30 years.
Btw if someone wants to ensure that no traffic from a local network is routed to an external network, then the edge router needs the have back hole route or null route as it also called.
Which means, simply black hole / drop everything to that destination regardless what the firewall might say or not.
Shouldnt you be able to accomplish this by adding a single custom table and chain that handles packets postrouting. Then just look at source or destination and reject anything from or to a defined set?
(Re: dlakelan) This is a UI issue, not a capabilities one. I already have the firewall doing what I want (so far as I can tell...) programming it only via LuCI. The problem is that I feel it is three times as much work to set it up as it should (2 IP Sets and 4 Traffic Rules vs. 1 IP Set and 1 Traffic Rule). This annoys me because I do not trust sysupgrade and so every time a new release comes out I re-enter all customization from scratch on my backup router before swapping it in.
(Re: brada) I speak only English, and do not use AI. Although I can play the "Asperger's card"....
And I do still believe that four rules are indeed necessary. Evidence in the "Status / Firewall" screen indicates that your Point 2 is not correct.
As for your Point 1, it would surprise me if the "stateful firewall" would be smart enough to automatically block an outgoing TCP SYN because other rules make it impossible for the TCP SYN-ACK to get through.
(Although just at the last minute I realize you might mean that the stateful firewall will poke a hole so that the SYN-ACK and further packets get through despite my input rule. Cool concept, but not what I intend to happen. I want a clean break with the shunned IPs.)
But that means I still need two rules (or four instead of two due to the other issue). I have to worry about incoming SYNs because the impetus for the shunning is the attempts to scan my port-forwarded mailserver for logins. (Those scans will never succeed as I don’t even use SMTP AUTH, but I want them out of my logs.)
The problem is not that OpenWRT can’t do it, it’s that the configuration is inconvenient. Generating the second rule automatically so that I only have to create one “Traffic Rule” object in LuCI would be simple. All that is needed is the extra “Reciprocal Action” field so that I can mark a Traffic Rule as needing such expansion and specify what form of block to use for the reverse path.
As far a i understand, @Michael_tlo is saying it would be beneficial to have a simple command / button in the UI to deny all traffic to and from a given IP in one go.
No messing with specific firewall rules, just “ban this IP”, done.
(re: axx) Close, but I wouldn’t want it quite that simple. A solution like you imagine could almost be done without coding by changing the default configuration to already include an empty “IDP” IP Set and the needed four rules already entered. But only almost, because there’s currently no way to say “Use this IP Set which happens to be src_ip, but apply it to destination IP instead for this one rule” in Traffic Rule configuration.
I might want to use more than one such rule. I currently have one quartet of rules blocking individual IPs, and a second blocking problematic CIDRs.
So really only a general “Make it bidirectional!” button on the configuration for any new Traffic Rule is enough. (But actually a dropdown rather than a button, since I want to change the action from “drop” to “reject” when reversing.)