iptables suddenly will not start

cylarz · 06-26-2008, 11:24 AM

Hi,

Running Fedora 9 from RedHat.

I have a bash script (set up as a cron job) that restarts my iptables firewall each day. This morning, I checked my mail to find that it wouldn't start. When I tried to run iptables manually just to find out which firewall rules were in place, I got the following:

/root#whereis iptables
iptables: /sbin/iptables /lib/iptables /usr/share/man/man8/iptables.8.gz
/root#/sbin/iptables -L
iptables v1.4.0: can't initialize iptables table `filter': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
/root#yum -y update
Loaded plugins: refresh-packagekit
Setting up Update Process
No Packages marked for Update
/root#

Huh? I don't know what insmod is, so I looked into it and found the following link:

http://linux.about.com/od/commands/l/blcmdl8_insmod.htm

...but I don't see how that has anything to do with my problem. This is a man page for installing kernel modules, and iptables is already isntalled according to the output above...or whereis wouldn't have found it. And the firewall script launched and ran iptables perfectly every day for literally YEARS prior to this morning. Why is it suddenly claiming "iptables who"? And as you can see, I'm running the latest kernel version - the yum command would have remedied this if I wasn't.

My cron job also runs the yum command each night, and it's possible that it may have picked up something-or-other which changed the system configuration, but I cannot imagine what.

I take it this means my firewall is down...?

Any ideas on fixing this would be appreciated.

Thanks, Matt

eagleheart · 06-27-2008, 08:21 PM

post the output of

lsmod |sort

jayjwa · 06-28-2008, 11:48 PM

iptables is the user-land side of Netfilter, the other part being the in-kernel code. You get weird messages like these when iptables (the user-land part) and the kernel code that provides the actual support don't match up. iptables should be built to match whatever kernel is current. On a distro system, my guess is these match up/are shipped out together. The actual module that provides the filter part I believe is "iptable_filter", as seen here:

Code:

ipt_MASQUERADE          3328  1
iptable_nat             6664  1
nf_nat                 17424  2 ipt_MASQUERADE,iptable_nat
ipt_REJECT              3712  18
xt_comment              1792  7
xt_multiport            2944  7
ipt_LOG                 5248  45
xt_limit                2432  45
nf_conntrack_ipv4      16008  5 iptable_nat,nf_nat
xt_state                2432  2
nf_conntrack           57488  5 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,xt_state
iptable_filter          3328  1
xt_iprange              2432  40

You shouldn't ever have to touch 'insmod'. Usually the kernel auto-loads what it needs, but you could do 'modprobe iptable_filter' and it might give you a better error message.

See if you have all the kernel modules for iptables (your kernel version will probably be different):

/lib/modules/2.6.25.9/kernel/net/ipv4/netfilter/ <-- should be a bunch of kmods in there
/usr/lib/iptables/ <-- and solibs in there

If you do have all that, then my next guess is that the user-land and the kernel code parts of iptables/netfilter are out of sync/don't match up.