The iptables-restore program fails if the saved configuration uses any
user-defined chains as jump targets. To show this in action, start off
with a clean system with no iptables rules defined. Run the following
# iptables -N user-chain
# iptables -A INPUT -j user-chain
# service iptables save
# service iptables restart
After thre restart command you will see the following diagnostic output:
iptables-restore v1.2: Couldn't load target
cannot open shared object file: No such file or directory
Try `iptables-restore -h' or 'iptables-restore --help' for more
An "iptables -L" command confirms that the tables have not been restored.
Direct inspection of the saved "/etc/sysconfig/iptables" file reveals no
problems in the file itself, suggesting that the bug is on the
iptables-restore side rather than the iptables-save side.
I observe this bug in the "iptables-1.2.0-10" RPM.
*** This bug has been marked as a duplicate of 28412 ***
Reopening bug since it was marked as a duplicate of a private bug which has not
been resolved yet. Bero, please add a comment to this bug on what the fix is
when the private bug is resolved.
Fixed in 1.2.1a-1