iptables-retore very slow
Daniel De Graaf
danieldegraaf at gmail.com
Tue Mar 6 21:32:08 CET 2007
iptables-restore has some flags that could be useful: --verbose,
--test (to prevent the actual sending back to the kernel), --noflush
(to prevent flushing already existing chains)
If that doesn't help at all, you could either use strace to find if it
is hanging on a syscall, or add #define DEBUG to the top of
iptables-restore.c and recompile to enable more debugging output.
Are there rules on tables other than filter? Those aren't flushed by
iptables -F and could possibly be slowing it down if there were many
Hope that helps,
Daniel De Graaf
On 3/5/07, Rackage | Randles <randles at rackage.com> wrote:
> I recently noticed that one of my firewalls was taking a very long time
> to reboot. Which was odd as its a very new machine.
> On investigation is seemed to be the iptables-restore command that was
> adding 10+ minutes to the boot-up times.
> I ran iptables-restore from a terminal and found that it was indeed
> taking an amazingly long time.
> Obviously I assumed it was related to the rules on the server, so I
> flushed all rules and all user defined tables from the firewall (nat,
> mangle and filter) and used iptables-save which took less than 1
> millisecond :) on the empty rule set.
> However iptables-restore is still taking 10+ minutes even with no rules
> to read / apply.
> Has anyone seen the behaviour before? or has anybody got some bright
> ideas on how I might continue debugging this issue?
> Thanks in Advance
More information about the netfilter