Eric Garver
Eric Garver
> @erig0 I wonder whether the UI (firewall-config) should warn if too many such entries are added then? It could guide the user to use an ipset. This scenario should...
> Overlapping entries is a minor issue that deserves a warning at most. It's not that simple. firewalld supports multiple backends each with their own nuances and bugs around coalescing...
I think that's fair. It should also be a very simple change. Below is probably sufficient. ```diff diff --git a/src/firewall/core/io/policy.py b/src/firewall/core/io/policy.py index 8de7604a0fb2..eb7961363b4c 100644 --- a/src/firewall/core/io/policy.py +++ b/src/firewall/core/io/policy.py @@ -395,7...
There are a lot of these quality of life enhancements that could be done. Just off the top of my head: - sort rich rules by `priority` - sort ports...
There is no plan for this. Can you be more specific about your use case? Can you share the iptables rules that you're using?
Seems like a duplicate of #1050.
Closing an duplicate of #1050.
The iptables backend has a limitation on chain length name. The limit in nftables is much higher, e.g. 255. This is fixable on the firewalld side. We could generate unique...
So here is what I'm thinking: - add `StrictForwardPorts` knob in `/etc/firewalld/firewalld.conf` - with `StrictForwardPorts=no` we keep the top-level `ct state dnat accept` rule - this is what's currently creating...
v1.3.4 is ancient. Is this reproducible on the latest v2.3.0? Newer firewalld has much better configuration/sanity checks, as well as a startup failsafe.