I am having some issues with the way the OpenWRT firewall works. As an example I have a rule between 2 networks allowing ICMP traffic. I have a constant ping running and when I delete this rule my constant ping keeps working. It is working because this is already an established session and removing the rule does not apply to established sessions. Every other firewall I have ever worked on does not do this and would block the exiting session as well. If I were to stop and start my ping aka make a new session the ping doesn't work as expected. I want to make it so any firewall rule changes also apply to established related traffic and I believe this is a change that needs to be made to the forward chain on my firewall.
Here is an old post on the same issue. I was wondering if there was an updated method on this or a way I can do it via Luci.
I have never seen this behavior on any other firewall. Can you give me models you have seen this on? I basically just want my forward chain to look at the other rules before it looks at the established related allow rule.
Ok I don't care about a host based firewall I am talking about an actual stateful network firewall. None of them keep allowing established traffic after you block it that is a security risk imo.
I think to fix this this is a change in the forward chain. It seems openwrt looks at the established/related allow before it looks at the traffic rules. I want to it to look at the traffic rules first and then the established/related allow last. I believe this is the correct way it should be. Is that possible?
So you should seriously investigate in all 3 network firewalls mentioned built around same security zones paradigm.
You can always kill states using conntrack -D
Yes I get that I can kill all sessions every time I want my firewall changes to be correctly applied but I really just want openwrt to behave like other network firewalls where it will start blocking established sessions right away without bouncing all my sessions.
Then remove that established connection from the connection pool. Install and use conntrack-tools.
But adding rules after establish related undermines the whole point of early hit a rule.
And no, IMHO this is correct behavior.
You allow a connection and later your state full firewall looks only if the connection is already in the pool. That's the whole point of a state full firewall.
If this is that important to you, an unorthodox option is to modify /usr/share/firewall4/templates/ruleset.uc, moving the relevant rule from the prepend to the append part involved in creating the forward chain.
Doesn't seem that absurd since every other network firewall works this way. I just want my firewall rule changes to apply to established related traffic. Fortinet does this, Juniper SRX does this, Cisco ASA does this, been a bit since I have used Palo Alto or PFsense but I believe they also do this as well. OpenWRT is literally the only network firewall I know of that keeps allowing established sessions after you've blocked it with a policy. Honestly what is the point of ever having a firewall if it can keep allowing traffic like this. That is a major flaw.
Thanks, I will test this when I can. Do you know why this would not be like this by default?
Edit: I guess a better question would be how would someone actually make a timed rule work? If you set a timer on a rule to deny things at certain times it wouldn't really work as established sessions would keep working.
Are we talking about this specific icmp rule or about rules in general?
(And all this vendor products have huge failures on their own so let us not open that can ok.)
In case you don't know: OpenWrt does not have its own firewall. It just uses the netfilter projects nftables. Anyhow, if in doubt hit the mailinglist with that question. It's actually a good one.
Let me reword my statement.
The behavior is correct. You programmed the firewall to look for a match on a rule. You enabled connection tracking. You also set the rule to match established related connections. The traffic you get matches a connection in the connection table.
So I case you want or have to cleanup your connection table you as the user has to do it. Sure your expectations can vary, I just want to highlight that it's not the flaw of nftables.
In principle it is doable
there are at least 3 unused scratchpads in ct - zone (16) label (128) mark (32), you store arbitrary origin rule in any, then conditionnaly on valid rule accept est/rel
not a complete rewrite but significant.
good wishlist item but serious work.
You should not use words like "real" in this context. I guess you just want to have certain behavior, but that does not make it more real. Anyway my advise to you, move away from OpenWRT if you do not like what it is, and build your own firewall and operating system, then it can be as "real" as you want it to be.
"real stuff" you are after just wipes state tables and picks up loose connections. As told not on NAT, have a long fight since you do not agree on viable enhancement not found in any other (linux) fw
lol I'm sorry if that offends you. I've noticed OpenWRT fans are the same as Apple fans. You guys praise something not matter how bad it is. Real network firewalls will not keep allowing established sessions after you block them. That is not secure. I get if all you have ever used are clunky linux firewalls that seems odd but trust me it should not be like this.
