iptables 1.3.7 tgz package
 

I've been compiling the iptables 1.3.7 bz2 package that came out in December since I cannot find a tgz package for Slackware 11. Kernel 2.6.20 is giving me trouble with iptables (I've compiled the kernel several times with a new .config setup and it flops on the iptables build). Is there a tgz file somewhere for iptables-1.3.7?

You could have a look at the source directory on a slackware mirror, to see how the slackware iptables package was built. ie with which options etc. It'll be in the SlackBuild script. You might even be able to build a new slackware package from it.

iptables 1.3.7 for kernel 2.6.20
 

If you need an iptables 1.3.7 tgz you can download the version I compiled for kernel 2.6.20.

http://www.prosoundsystem.com/slackw...3.7-i686-1.tgz

Thanks for the package (I just downloaded it)...how did you get it to work with kernel 2.6.20?

...
 

I didn't =). The package was compiled against a 2.6.19.x kernel after realizing 1.3.5 didn't work with the new kernels. There shouldn't be any problems with running it with 2.6.20. Perhaps someone else can comment on this.

I'm using the iptables-1.3.5-i486-2 package on my Slackware 11 boxes - the kernels are all either 2.6.19.2 or 2.6.20. It sounds more like the .config options for OPs kernel are the problem.
Could you post the error/s that you get during compilation please?

Well, when I try to compile the iptables package from source I get building dependencies then nothing to do. When my pc reboots and loads up my iptables rules I get an error in line 11 of the rules file that worked fine in kernel 2.6.19.2

Oh, and when I try to list the iptables rules I find out that no rules were read.

What I did was to keep iptables 1.3.5 and when upgrading the kernel I ran make mrproper, copied over my old .config file, ran make oldconfig, make, make modules_install.

I take it that you're still running 1.3.5 because the new one didn't compile. Can you post your iptables rules? It should be possible to identify what it's trying to load and determine what's missing in your new kernel. Alternatively, what are the dependency errors you get with iptables 1.3.7?

iptables 1.3.5 errors
 

Attempting to load iptables rulesets w/ kernel 2.6.19+ results in errors such as "Unknown error 4294967295" in stdout. After trying to load a rule and receiving one of these errors, filtering no longer works and networking is effectively shut down.

This bug was fixed in 1.3.6. The changelog can be viewed here.

It's not a case of improper kernel config, 1.3.5 just flat out doesn't work with 2.6.19+.

There's more to it than that - I don't like saying "it works on my setup", but it does - and on multiple boxes.

At this point I'd like to know what errors linuxhippy is getting and what are the missing dependencies. If there are particular targets that cause the errors, do they need to be used?

Here's the exact error I get when I try to build iptables-1.3.7 now with kernel 2.6.20.1. I type this:

make /usr/src/linux-2.6.20.1

It says building dependencies and then after a couple minutes:

nothing to be done

Then I type:

make install /usr/src/linux-2.6.20.1

I see the screen fill up while it does compiling and then I get this:

make: Nothing to be done for `/usr/src/linux-2.6.20.1'

On reboot into the new kernel, all looks ok except that I get this statement:

iptables-restore: line 11 failed

When I do iptables --list my rules are not there. What do I need to do?

You need to to just type 'make' without the kernel directory. If that needs to be specified then just create the link /usr/src/linux to whichever kernel source tree you want. It also helps make things easier and more accurate sometimes if you are also running the kernel version you want to build for. I had no trouble compiling iptables-1.3.7-20070225 with kernel 2.6.20.1.

How are you loading your ruleset? Do you load via an rc.firewall script in /etc/rc.d? If you have a script that runs each time the system boots try adding each rule line by line until the system returns an error for the invalid rule, then post here.

Didn't work. I didn't get the message that nothing was done when it built dependencies, though. When I rebooted I still got the message about iptables-restore not being loaded.

Should I first uninstall iptables 1.3.7 from my old kernel?

It's clear from your previous posts that you should use the iptables package that's included with Slackware. The kernel support for packet filtering is netfilter, and it's part of the actual kernel. The iptables package is only the userspace portions, and it's built separately from the kernel. Until/unless you understand this distinction and how it affects what you're trying to do, you should stick to the distribution-provided packages.

I disagree. Load the rules from a script such as /etc/rc.d/rc.firewall and all will work fine. I've never trusted the iptables-restore as I like to know exactly what is being loaded into the ruleset.

The iptables package included with slackware 11 is simply outdated. There were no specific options for the package. Simply build the source from netfilter.org and load the rules via script instead of using the restore function. The link I posted above to the iptables 1.3.7 package works with 2.6.18+. Try it out and see for yourself.

*NOTE* Unless the proper modules were built for or included with the kernel currently running then yes, iptables will return errors due to unsupported features. Manually load the modules or recompile a kernel with proper feature support for iptables.

You disagree with what exactly? I did not suggest that the original poster should or should not use the iptables-save(8) and/or iptables-restore(8) functions. For that matter, they *do* work fine, they are built with the default Slackware iptables package, and if you understand how they work, then you *will* know "exactly what is being loaded into the ruleset."

How is it outdated? What do you mean by options? What functionality is missing from the stock iptables package?

Is there some *legitimate* need to have the latest version of iptables on your system, or are you simply wanting some shiny new version number?

No thanks - I can't seem to find any desire to try some random person's package, especially something as critical as iptables. If you are truly concerned about security, perhaps you should rethink the decision as well...

Yes, but then, that's exactly what I was trying to get across to linuxhippy in my reply. His question of "Should I first uninstall iptables 1.3.7 from my old kernel?" indicates a clear misunderstanding of the relationship.

This is getting old. It's obviously the more seasoned vets are not having any problems. Instead of using the save/restore function in iptables I suggest you create an rc.firewall script and have that load during boot. I believe /etc/rc.d/rc.inet1 or rc.inet2 calls the rc.firewall script.

The package I built for 1.3.7 and posted in a previous link works fine with 2.6.18+. Try it yourself if you don't believe me. The issue here is that 1.3.5 DOES NOT WORK with 2.6.20. This is reported on the netfilter.org website in the iptables changelogs. Telling him to use the 'official' slackware 11 package is pointless because it DOES NOT WORK with 2.6.20.

This is informative. It seemed as if iptables-1.3.7 compiled ok for kernel 2.6.20.1 and I just have a problem with the iptables-restore program which doesn't have to be used. I guess there's a difference between iptables-restore and iptables? My iptables rules are in /etc. I'm obviously an amateur at this-my degree is in civil engineering and not pcs!

Yes, at least one "more seasoned vet" is telling you that the iptables-1.3.5 package works fine.
As you can see here:
bash-3.1# iptables-save > /etc/iptables
bash-3.1# iptables-restore < /etc/iptables
bash-3.1#
the iptables-save(8) and iptables-restore(8) functions work just fine. I normally load my rules from the /etc/rc.d/rc.firewall script (which, for the record, is called from /etc/rc.d/rc.inet2), but for your benefit, I just verified that the two save/restore functions work as advertised.

Oh really? Explain this then.

bash-3.1# uname -a
Linux isotope 2.6.20 #1 SMP PREEMPT Tue Feb 6 18:49:52 CST 2007 i686 pentium4 i386 GNU/Linux
bash-3.1# iptables --version
iptables v1.3.5
bash-3.1# ls /var/log/packages/iptables-1.3.5-i486-2
/var/log/packages/iptables-1.3.5-i486-2

ok, I followed the advice of loading each rule individually and found (I think) the offending rule:

-A INPUT -m state --state ESTABLISHED -j ACCEPT

This rule loaded up fine in the other kernels....what do I need to enable now in the .config for the kernel?

You need to have connection tracking enabled in the netfilter section of the kernel config. Like most of my recommendations, I suspect that this might be ignored, but I suggest enabling *all* of the netfilter-related items as modules (except for the ones marked as deprecated or obsolete), even if you don't think you need them - they won't hurt anything, and that way, you won't have to go into troubleshoot mode later as your knowledge base increases and you decide to try some of the more advanced features it offers.

that was it....I have iptables-1.3.7 booting fine with kernel-2.6.20.1. After booting into the new kernel I built iptables with only make and make install and a sym link between /usr/src/linux and /usr/src/linux-2.6.20.1. The .config file for the kernel (using menuconfig) had all the options enabled in:

Networking>Networking Options>Network Packet Filtering Framework>Core Netfilter Configuration

I'm willing to bet some dignity on this - remove that iptables version and reinstall the stock Slackware package (iptables-1.3.5), and you'll see that it works as expected.

Also, don't forget to remove the custom iptables binaries and libraries if you later want to install/upgrade it with an official Slackware package. Unless you changed it, you installed it to /usr/local. Official (and most unofficial) packages will install to /usr, so you'll wind up with two sets of iptables files, and the one in /usr/local will usually override the one in /usr unless the path is explicitly defined in scripts and such.

You didn't need the symlink at all - iptables looks in /lib/modules/$(uname -r)/{build,source} for the running kernel source. See this link for a bit more information on that: http://www.linuxquestions.org/questi...04#post2629704

RW

I get peace of mind from using the latest stable version of software so I keep my kernel and iptables current. I don't know enough about pc security to use the snapshots of iptables. Thanks for all the help here!

There haven't been an security fixes in iptables since 1.3.5 (actually, since quite a bit before that). Building newer versions for no good reason, especially if it makes things more difficult to maintain later if/when new packages are released by the distribution, can actually be detrimental to security. A system that is difficult to maintain will often not *get* maintained. Ultimately, it's your system, so admin it as you see fit, but be wary of getting caught up in the constant rush of staying current with latest version numbers...

If you're wanting the latest *stable* version of a 2.6 kernel for a production system, you should probably lean toward 2.6.16.x (which is currently at 2.6.16.42) - that kernel series is going to maintained long-term with security and reliability fixes.

I didn't know that the 2.6.16.x kernel was still being kept current. I just went to the Linux Kernel archive and see that it was updated about the same time as 2.6.16.42. Maybe I'll do that.

I have iptable tgz packages installed for 1.3.5 and 1.3.6. I have been building 1.3.7 for each stable kernel update since December. How would I go back to iptables 1.3.5?

Your call :)

This is what I was referring to earlier about the distinction between netfilter (the kernel portion of the linux packet filter) and iptables (the userspace portion). Generally speaking, there is no need to rebuild iptables (the userspace portion) with each new kernel release. Granted, if you want the shared library for the recent match to be built, you have to build against 2.6.x kernel sources, and there have been a few instances of (mostly temporary) breakage of iptables compilation on new kernels, but anyway, to answer your question: You will need to remove the custom-installed iptables stuff (there should be an 'uninstall' target in the Makefile), and just to be safe, removepkg both of the installed iptables packages. Once you're done, install either the stock iptables-1.3.5 package (or the iptables-1.3.6 package from /testing if you want to go that route, but 1.3.5 should suffice).

With all that said, if you *really* want to run the latest version of iptables, then please, for your sake, consider using the SlackBuild script and associated files available at http://slackware.osuosl.org/slackwar...ptables-1.3.6/
See http://slackbuilds.org/howto/ for an idea of how to work with that. The benefit of using the SlackBuild script is that it will build a package that you can install/upgrade/remove with the standard pkgtool(8) suite.

wow-SlackBuild looks good! I now have something new to mess with-thank you!

Success
 

Thanks to all who contributed to this thread. Very useful.

Had the same problem with my FC6 installation when I tried to update the kernel to a custom 2.6.20.2 just now. Got error during boot saying iptables-restore failed at line 27 (which is the commit statement in my case).

I run 'make menuconfig' again and went into:
Networking>Networking Options>Network Packet Filtering Framework>Core Netfilter Configuration

Enabled everything as modules in there, then make, reinstall kernel and modules, reboot, problem solved :D

Mons
Edit: just for completeness, the iptables version I have is 1.3.5 and when loading the lines in /etc/sysconfig/iptables one by one, the failing line is a similar one to robw810 above (...state ESTABLISHED...). That's just if others get the same problem, all green 'OK's on my machine now :)