SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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.
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."
Quote:
The iptables package included with slackware 11 is simply outdated. There were no specific options for the package.
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?
Quote:
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.
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...
Quote:
*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.
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.
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.
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.
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu, Mint 18.1, Debian Jessie
Posts: 1,207
Original Poster
Rep:
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!
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.
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.
Quote:
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.
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.
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu, Mint 18.1, Debian Jessie
Posts: 1,207
Original Poster
Rep:
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:
that was it....I have iptables-1.3.7 booting fine with kernel-2.6.20.1.
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.
Quote:
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.
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
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu, Mint 18.1, Debian Jessie
Posts: 1,207
Original Poster
Rep:
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!
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.
Distribution: Xubuntu, Mythbuntu, Lubuntu, Picuntu, Mint 18.1, Debian Jessie
Posts: 1,207
Original Poster
Rep:
Quote:
Originally Posted by robw810
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?
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.
Your call
Quote:
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?
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.
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
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.