SNAT and MASQUERADE, at mimimum, are broken if iptables isn't recompiled against
a newly-installed 2.4.21 kernel. I can't find anything in either the
vanilla-sources or iptable ebuilds that recognizes or notifies about this
Steps to Reproduce:
1. Upgrade to 2.4.21 (vanilla-sources) with SNAT and/or MASQUERADE included
2. Run a command like "iptables -t nat -A POSTROUTING -o etho -j MASQUERADE" (or
3. Get an error message ("iptables: Invalid argument") and no joy with SNAT or
MASQUERADE (although many other iptables commands work fine).
*** This bug has been marked as a duplicate of 1991 ***
Why not as a partial solution until the very old bug 1991 is addressed have the ebuilds for downloading new kernels provide the information to stdout that the user should emerge iptables again afterwards if installed? That informational mechanism is already in place. A solution to 1991 would be better. But this is an unusual situation where updating kernels in the 2.4 serious prior to 2.4.21 did not require recompiling iptables. At 2.4.21 it does, and with no notice of this the user can have to go to considerable trouble to discover what went wrong, when a simple notice in the ebuild that downloads the kernel source would have prevented that trouble.
This isn't really a bug as kernel modules have to be rebuilt when moving
other kernels. The same applies both to iptables, NVIDIA drivers, I2C, ...
... ... and thus forth. NOTABUG.
plasmaroo fails to understand the bug report - perhaps I wasn't clear. It's
not about kernel modules - it's about the iptables ebuild, which contains
the utilities for loading firewall rules, irrespective of whether iptables/netfilter
support has been built into the kernel or built as kernel modules. The bug
is that the iptables package itself has to be freshly emerged after building
and installing the new kernel, or else some firewall rules will unexpectedly
and inexplicably fail to load correctly. Again, building modules does not
cause the iptables package to be rebuilt, so plasmaroo hasn't understood
the problem. Partial failure of the firewall is a serious security risk,
as well as causing other sorts of networking failures in production environments.
This bug still needs to be addressed.
In which case I'm reassigning this to bug-wrangling as I see no kernel problems
here and the bugs seem to lie in the iptables ebuild...?
There is no bug in the iptables ebuild. This problem exists even if building
the kernel and iptables by hand - you can find discussion of it on the netfilter
list. The kernel code that supports iptables changed significantly enough
in version 2.4.21 that iptables needs to be rebuilt after upgrading the kernel.
This is a dependency therefore that the kernel ebuild needs to somehow address.
I think I have seen a informational message added there since this was first
reported? Maybe that's all that can be done.
Note iptables did not need to be rebuilt to keep working from early in the
2.4 series through 2.4.20 (at least not in my experience) - this appears
to be specific to going from <= 2.4.20 to a higher kernel version. So having
a new kernel build always rebuild iptables might be overkill.
what Whit Blauvelt says.
You'll need to recompile iptables at every major version change, due to code
and structure changes. If it just works, you simply had luck.
If what you say is true, then providing someone hasn't added this information
to the Gentoo docs since I last looked, it is still a _documentation bug_.
My own best knowledge is that it's not true - that through a number of major
version changes the netfilter code and structures stays largely the same,
but occassionally (e.g. between 2.4.20 and 2.4.21) undergoes changes major
enough to require recompling iptables. But I haven't audited the code - I'm
just going by the netfilter list discussions and personal experience.
Still, the best resolution of the bug may be to treat it as a documentation
bug until it is added someplace prominent enough in the Gentoo docs as to
make it common knowledge. On a number of systems I run (with different distros,
although I always compile my own kernel.org or -ac kernels) iptables did
not need to be recompiled between early in the 2.4 series and 2.4.21, and
I use many of its features. (Similarly ipchains stayed good through the 2.2
series.) So it will not be common knowledge from experience for those going
from <= 2.4.20 that it needs to be recompiled, and it would be good to make
sure this knowledge is shared, wouldn't it, considering the security and
network stability issues?
aliz, please add an einfo section to iptables
Added small einfo