Re: Reload IPtables

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Mon, Jun 28, 2021 at 10:02:41PM -0400, Neal P. Murphy wrote:
> On Mon, 28 Jun 2021 10:43:10 +0100
> Kerin Millar <kfm@plushkava.net> wrote:
> 
> > Now you benefit from atomicity (the rules will either be committed at once, in full, or not at all) and proper error handling (the exit status value of iptables-restore is meaningful and acted upon). Further, should you prefer to indent the body of the heredoc, you may write <<-EOF, though only leading tab characters will be stripped out.
> > 
> 
> [minor digression]
> 
> Is iptables-restore truly atomic in *all* cases?

Packets either see the old table or the new table, no intermediate
ruleset state is exposed to packet path.

> Some years ago, I found through experimentation that some rules were
> 'lost' when restoring more than 25 000 rules.

Could you specify kernel and userspace versions? Rules are not 'lost'
when restoring large rulesets.

> If I placed a COMMIT every 20 000 rules or so, then all rules would
> be properly loaded. I think COMMITs break atomicity.

Why are you placing COMMIT in every few rules 20 000 rules?

> I tested with 100k to 1M rules.

iptables is handling very large rulesets already.

> I was comparing the efficiency of iptables-restore with another tool
> that read from STDIN; the other tool was about 5% more efficient.

Could you please specify what other tool are you refering to?

iptables-restore is the best practise to restore your ruleset.

You should also iptables-restore to perform incremental updates via
--noflush.