[Bug 260796] ipfw: net.inet.ip.fw.dyn_keep_states=1 : packets silently vanish

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 29 Dec 2021 12:47:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260796

            Bug ID: 260796
           Summary: ipfw: net.inet.ip.fw.dyn_keep_states=1 : packets
                    silently vanish
           Product: Base System
           Version: 12.3-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: pmc@citylink.dinoex.sub.org

net.inet.ip.fw.dyn_keep_states=1 will keep dynamic rules (for currently active
connections) when the original stateful rule is deleted. 
The resulting behaviour is obvious when the corresponding action is finite
(e.g. allow, deny).
But when the corresponding action is NOT finite (e.g. count, tag) and when
net.inet.ip.fw.one_pass=0, then processing of further rules should continue at
the point after the original stateful rule (which does no longer exist).

In this case the current implementation redirects the rule processing to the
final default rule 65535 (which normally is an unconditional unlogged deny),
and so the respective packet does silently vanish.
While this may be the most safe assumption, it is practically useless.

A properly crafted ruleset can be made able to continue proper processing at
the respective original line-number even after it has been refactored and
reloaded (e.g. nonfinite stateful rules always followed by a "return" rule). In
that case it should be possible to have dyn_keep_states continue processing
after the original line number.
I successfully obtained that desired behaviour by just removing the respective
line from the code in sys/netpfil/ipfw/ip_fw_dynamic.c

I might propose a second option dyn_keep_states=2 to obtain this behaviour. Or,
alternatively, dyn_keep_states might contain the actual rule number where
processing should continue.

-- 
You are receiving this mail because:
You are the assignee for the bug.