Date: Wed, 29 Dec 2021 12:47:57 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 260796] ipfw: net.inet.ip.fw.dyn_keep_states=1 : packets silently vanish Message-ID: <bug-260796-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D260796 Bug ID: 260796 Summary: ipfw: net.inet.ip.fw.dyn_keep_states=3D1 : 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=3D1 will keep dynamic rules (for currently a= ctive connections) when the original stateful rule is deleted.=20 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=3D0, then processing of further rules should contin= ue 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 respect= ive line from the code in sys/netpfil/ipfw/ip_fw_dynamic.c I might propose a second option dyn_keep_states=3D2 to obtain this behaviou= r. Or, alternatively, dyn_keep_states might contain the actual rule number where processing should continue. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-260796-227>