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