On Tue, 29 Jun 2021 10:52:38 -0400 slow_speed@xxxxxxx wrote: > On 6/28/21 10:02 PM, Neal P. Murphy wrote: > > On Mon, 28 Jun 2021 10:43:10 +0100 > > Kerin Millar <kfm@xxxxxxxxxxxxx> 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? Some years ago, I found through experimentation that some rules were 'lost' when restoring more than 25 000 rules. If I placed a COMMIT every 20 000 rules or so, then all rules would be properly loaded. I think COMMITs break atomicity. I tested with 100k to 1M rules. I was comparing the efficiency of iptables-restore with another tool that read from STDIN; the other tool was about 5% more efficient. > > > > Please explain why you might have so many rules. My server is pushing > it at a dozen. In this particular case, I needed a lot of rules to obtain a reasonable estimate of the relative efficiencies of the two programs, enough rules to mask program initialization time. I agree that tens of thousands of rules is probably outrageous for most purposes. A good firewall--that restricts outgoing conns, handles TESTNET addresses, isolates traffic between several internal LANs while allowing certain traffic to pass between them, employs NAT, and uses CONNMARKs to tag traffic and to provide traffic stats--can easily use over 600 rules, if not a good deal more. Yet a 1.6GHz Atom N270 can still process four saturated gigE NICs with plenty of cycles to spare with those 600 rules. N
