Bug 87715

I've found that while removing the "-c" switch from iptables-save prevents the 
packet counts for the individual rules from being saved, it doesn't inhibit the 
saving of the packet counts for the built-in chains. The only way to get around 
that, it appears, is to remove the "-c" switch from the iptables-restore 
command (also in /etc/init.d/iptables) too.

Fixed in the new 1.2.8-4.x version. This version has a new startup script and an
additional config file.


/etc/sysconfig/iptables-config:
> # Additional iptables modules (nat helper)
> # Default: -empty-
> #IPTABLES_MODULES="ip_nat_ftp"
> 
> # Save current firewall rules on stop.
> # Value: yes|no,  default: no
> #IPTABLES_SAVE_ON_STOP="no"
> 
> # Save current firewall rules on restart.
> # Value: yes|no,  default: no
> #IPTABLES_SAVE_ON_RESTART="no"
> 
> # Save rule counter.
> # Value: yes|no,  default: yes
> #IPTABLES_SAVE_COUNTER="yes"
> 
> # Numeric status output
> # Value: yes|no,  default: no
> #IPTABLES_STATUS_NUMERIC="no"


RPM packages for 7.x:
http://people.redhat.com/twoerner/RPMS/7.x/iptables-1.2.8-4.73.1.i386.rpm
http://people.redhat.com/twoerner/RPMS/7.x/iptables-ipv6-1.2.8-4.73.1.i386.rpm
http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-4.73.1.src.rpm

RPM packages for 8.0:
http://people.redhat.com/twoerner/RPMS/8.0/iptables-1.2.8-4.80.1.i386.rpm
http://people.redhat.com/twoerner/RPMS/8.0/iptables-ipv6-1.2.8-4.80.1.i386.rpm
http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-4.80.1.src.rpm

RPM packages for 9:
http://people.redhat.com/twoerner/RPMS/9/iptables-1.2.8-4.90.1.i386.rpm
http://people.redhat.com/twoerner/RPMS/9/iptables-ipv6-1.2.8-4.90.1.i386.rpm
http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-4.90.1.src.rpm

> #IPTABLES_SAVE_COUNTER="yes"

Your changed scripts don't restore the saved counters anymore upon running
iptables-restore. Hence this option is useless. Btw, tell me one good reason why
anyone would want to save byte/packet counters into /etc/sysconfig/iptables?

> #IPTABLES_SAVE_ON_RESTART="no"
> 
> # Save rule counter.
> # Value: yes|no,  default: yes
 
Default is "no", but I think those two (SAVE_ON_STOP and SAVE_ON_RESTART) are
over-ambitious. In the world of scripting, it's so quick'n'easy to simply run
"service iptables save ; service iptables restart".


Whether removing modules manually in stop() is a good idea remains to be seen.
While I like the new $IPTABLES_MODULES feature for specifying a list of modules
to be modprobe'd, the stop() function interferes with stacking modules via
/etc/modules.conf. I say: Please don't remove kernel modules unless user tells
you to do so explicitly.


An option for making status() list tables verbosely would be nice.

IPTABLES_SAVE_COUNTER also affects iptables-restore, now (forgot '-c').

There are people, that want to save and restore the counters when the machine
gets rebooted or when the firewall gets restarted.

To unload the kernel modules is the only way to get the firewall to a real stop:
Think of the nat helper or the conntrack modules. As an example: I have to
unload the modules if the user decides to not use a helper anymore or if the
user wans to switch to ipchains.

This looks great, but shouldn't IPTABLES_SAVE_COUNTER default to "no" since 
IPTABLES_SAVE_ON_{STOP,RESTART} default to "no"? I can't imagine why anyone 
would want to save packet counts when they aren't writing the rules at shutdown.

Okay, when documented well, there won't be unexpected problems.


In the following, "echo; return 1" looks badly misplaced. Actually, it prevents
the rest of the start function from being executed:

start() {
...
    echo -n $"Applying $IPTABLES firewall rules: "
    $IPTABLES-restore $IPTABLES_DATA && success || failure; echo; return 1
    echo
...


Also, with IPTABLES_MODULES="ip_nat_irc", "service iptables start ; service
iptables stop" fails to remove "ip_conntrack_irc" and "ip_conntrack" here with
Shrike.

Here are the latest updates:

- IPTABLES_SAVE_COUNTER defaults to no, now
- installs config file in /etc/sysconfig
- exchanged unload of ip_tables and ip_conntrack
- fixed start function

Update packages for 7.x:
http://people.redhat.com/twoerner/RPMS/7.x/iptables-1.2.8-5.72.1.i386.rpm
http://people.redhat.com/twoerner/RPMS/7.x/iptables-ipv6-1.2.8-5.72.1.i386.rpm
http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-5.72.1.src.rpm

Update packages for 8.0:
http://people.redhat.com/twoerner/RPMS/8.0/iptables-1.2.8-5.80.1.i386.rpm
http://people.redhat.com/twoerner/RPMS/8.0/iptables-ipv6-1.2.8-5.80.1.i386.rpm
http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-5.80.1.src.rpm

Update packages for 9:
http://people.redhat.com/twoerner/RPMS/9/iptables-1.2.8-5.90.1.i386.rpm
http://people.redhat.com/twoerner/RPMS/9/iptables-ipv6-1.2.8-5.90.1.i386.rpm
http://people.redhat.com/twoerner/SRPMS/iptables-1.2.8-5.90.1.src.rpm

Works for me.


Now please verify the IPv6 package: While it may look smart to generate the
ip6tables initscript from the IPv4 version, it introduces a few bugs:

 - "nat" table is not available in IPv6 netfilter and gives an error
 - there is no IPv6 netfilter connection tracking
 - rmmod_r() calls unload IPv4 netfilter modules