ipfw managing rules - best practice?

[Rodney W. Grimes]

> Wed, 5 Sep 2018 18:33:58 +0300 - "Andrey V. Elsukov"
> <bu7cher at yandex.ru>:
> 
> > On 05.09.2018 12:28, Ole wrote:
> > > I understand, that this connections get broken because the dynamic 
> > > rules get flushed with the `ipfw -q -f flush` command. But
> > > commenting this command out results in a continuously growing rules
> > > table.
> > > 
> > > With the `ipfw -d list` command I can see the dynamic rules. 
> > > Is there a way to flush the rules but not the dynamic ones?
> > > Or to add them again after flush?  
> > 
> > There is net.inet.ip.fw.dyn_keep_states sysctl variable. It allows to
> > keep dynamic state when parent rule is deleted. But you need to use
> > default_to_accept firewall to make it working.
> > I plan to reimplement this feature to be more useful and work with any
> > rules, and not only with "allow" rules.
> 
> Ah, thank you very much. This is exactly what I was searching for. I
> deployed it to some machines and it is working well.
> 
> One Question: I have lots of hostname dependend rules in lots of jails.
> Do you think it  is OK to reload the ruleset every 5 min by cron to
> re-resolv the hostnames?

Your milage may vary depending on what your doing,
but here are some ideas.

My prefered method for dealing with lots of IP/hostnames in
ipfw rule sets is to place them all in different tables and
then just flushing and rebuilding the tables rather than the
whole rule set.

I can think of using the value in the table to indicate
what generation that IP belongs to and doing some fancier
things that would do the lookups and add them to the table
as generation n++, then when finished iterate over the
table and delete all generation n IP's, then bump the
generation number which can be stored in the table on
0.0.0.0/32 (not default, but literaly the all 0's address,
or some other magic token.

I have done that type of thing from a C program for
other usses, not for name resolving.


-- 
Rod Grimes                                                 rgrimes at freebsd.org