iptables-retore very slow

[Daniel De Graaf]

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
of them.

Hope that helps,
Daniel De Graaf

On 3/5/07, Rackage | Randles <randles at rackage.com> wrote:
> Hi,
>
> 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
>
> Regards
>
> Ben
>
>
>