From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1 i586) The /etc/rc.d/init.d/iptables initscript goes to considerable lengths to flush/clear/reset the INPUT, OUTPUT, and FORWARD chains in the "filter" table. However, this is not the only table! Systems doing masquerading will also be using the "nat" table. Systems doing packet rewriting will also be using the "mangle" table. Additional tables might appear in the future, or in certain local configurations. Reproducible: Always Steps to Reproduce: 1. service iptables stop 2. iptables -t nat -A POSTROUTING -j ACCEPT 3. service iptables stop 4. iptables -t NAT -L POSTROUTING Actual Results: Output from the final "iptables ... -L ..." command shows that there is still a rule on the POSTROUTING chain in the "nat" table: Chain POSTROUTING (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere Expected Results: The second "service iptables stop" command should have cleared out *all* tables. The output from the final "iptables ... -L ..." command should have showed an empty POSTROUTING chain in the "nat" table: Chain POSTROUTING (policy ACCEPT) target prot opt source destination The most general solution here is to not hard-wire the list of tables into the script. Rather, the script should read "/proc/net/ip_tables_names", which will always be a newline-delimited list of tables active in the kernel at that moment. Flushing all rules in all chains in all tables should be easy enough with something like the following: for table in `cat /proc/net/ip_tables_names`; do iptables -t $table -F done What's less obvious is how to reset all chains to their default policies. The "/proc/net/ip_tables_names" file makes it easy to avoid hard-wiring the list of tables, but I'm not sure how to avoid hardwiring the list of built-in chains for each table.
We (Red Hat) should really try to resolve this before next release.
One suggestion on how to avoid hardcoding the list of chains for each table would be to parse the output of iptables -L if we're willing to rely on that....
The scripts seem to have been updated for wolverine. Now the scripts assume that the "filter", "nat", and "mangle" tables are always present. That's just as bad in the opposite direction. What if I don't have all of those tables in my kernel? What if I have some additional tables defined by locally created modules? The init scripts cannot hard wire a list of tables, period. They must discover the list of tables by looking at "/proc/net/ip_tables_names", as I suggested in my original bug report. This bug report is already tagged "fisher". Should I submit a new bug report against wolverine?
Looks like bug #29104 already describes this new wolverine issue. Disregard my question about filing a new report.
Fixed in 1.2.0-9