ipfw: switching sets does stall the machine
Andrey V. Elsukov
bu7cher at yandex.ru
Sun Jun 16 19:08:51 UTC 2019
On 14.06.2019 23:13, Peter wrote:
> 2. There are dynamic rules involved. These do not disappear on a
> "set disable". They stay and continue to function - somehow.
>
> 3. When a packet successfully matches a check-state, it does NOT
> continue to be processed at the rule following that check-state.
> Instead, it does continue to be processed at the place after
> the parent keep-state rule that was originally matched!
>
> But what if that keep-state rule is now disabled, and the new
> rules do not line up in their numbering in the exact same way?
> Then this packet appears at some arbitrary place in the rule
> list and may go to whereever.
Dynamic rules use only "action" part of parent rule, so when dynamic
state is "applied" to a packet, it just executes action of parent rule
without checking the set to which belongs the rule.
But then, if a packet processing is continued, the next rule checked
from the beginning, and thus its set is checked.
> Obviousely this is not an issue if you do keep-state with simple
> Allow or Deny rules - then the packets leave the system after
> matching.
> But such simple keep-state do not work with NAT. For NAT one needs
> a more elaborate approach, like tagging and branching and
> subroutine calling.
>
> So the outcome is:
>
> When switching sets with such a configuration that introduces
> branches and subroutines, the old and new rules need to precisely
> line up to each other, so that the old dynamic rules (which should
> be kept for the network sessions to persist) can reinsert their
> matched packets at places where correct further processing happens.
>
> Doesn't seem like an easy task...
You may try 11.3-BETA where new implementation of dyn_keep_states was
committed. When you set net.inet.ip.fw.dyn_keep_states=1, the dynamic
states aren't deleted with their parents rules. They are kept until
expiring or explicit deletion (with -D flag). But the next rule for
states that don't stop packet processing is the last rule. This is
probably will not fit your requirements.
--
WBR, Andrey V. Elsukov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 554 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ipfw/attachments/20190616/4d9d8e08/attachment.sig>
More information about the freebsd-ipfw
mailing list