Why do these 3 rules cause problems for me in iptables? (COMMIT line error)

Question

I am trying to export my rules from one server to another, but for some reason they fail on one. One server is Xen and the other OpenVZ (this one is the one causing trouble). They are both running Ubuntu (though different versions, 8.04 and 10.10 respectively) and also different versions of iptables (1.3.8 and 1.4.4 respectively).

I exported my rules fine, but when I run them I'm getting an error on the COMMIT line. So I commented out each line in my rules one by one and discovered these three lines are the culprits:

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p tcp -m state --state NEW --dport 23 -j ACCEPT
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

What is wrong with these lines? They look fine to me and they run fine on my Xen server...

This is the contents of the original rules file:

*filter


#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT


#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


#  Allows all outbound traffic
#  You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT


# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT


# Allows Tomcat, sms, and newrelic
-A INPUT -p tcp --dport 8080 -j ACCEPT
#-A INPUT -p tcp --dport 8009 -j ACCEPT


#  Allows SSH connections
#
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
#
-A INPUT -p tcp -m state --state NEW --dport 23 -j ACCEPT


# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT


# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7


# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

UPDATE:

Ok, so it looks like the only thing in common between all three of these is the option "-m", none of the rules which work have that option... what gives?

Have you tried feeding the lines into iptables one by one? That should give you an idea where the problem really is. — wolfgangsz, May 19 '11 at 08:15
@wolfgangsz: yup, looks like there are 3 lines causing me trouble, i've reworded the question and posted my results above. — GiH, May 20 '11 at 00:38

score 2 · Accepted Answer · answered May 20 '11 at 08:35

2

The errors are probably related to the fact that you need to load the relevant kernel modules before some of the options can be executed. Depending on the distro, some of these are loaded by default and others may be loaded automatically if certain options are used. It would appear that in your case you may need to load some manually, using modprobe.

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

In order to use a state condition, you need to load the ip_conntrack module.

-A INPUT -p tcp -m state --state NEW --dport 23 -j ACCEPT

Same issue here

-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

Not sure why this one is causing a problem.

I would recommend reading the man pages for iptables on that particular distro very carefully, then examine which kernel modules are loaded and possibly add some lines at the top of the batch file to load required kernel modules.

Here is the relevant output from one of our public gateways, which uses similar iptables rules.

#> lsmod | grep ip
iptable_mangle         11392  0 
ipt_recent             16672  2 
ipt_LOG                13828  4 
iptable_nat            13840  0 
nf_nat                 25496  2 nf_nat_ftp,iptable_nat
ipv6                  287784  65 sit
dm_multipath           23704  0

answered May 20 '11 at 08:35

wolfgangsz

8,847
3
30
34

Thanks wolfgangsz, I'll contact my VPS provider because I don't think I can load things into the kernel myself on a shared server right? Also, the new server, when I run lsmod | grep ip, I get nothing, but when I run it on the old server I get something very similar to yours, with 2 extra modules (specifically the nf_conntrack and nf_contrack_ipv4. Any suggestions before I contact my provider? – GiH May 20 '11 at 13:59
In order to load kernel modules you will probably need root access. Do you know whether you have sudo rights? You could just try to load a kernel module and see what happens. I know this sounds a little guerilla like, but AFAICT there is no real danger. – wolfgangsz May 20 '11 at 14:15
Yup I do have root access, so I'll give it a go then. Do you have a link for how to get the kernel modules loaded on? Also, any idea why nothing is showing up in lsmod | grep ip? I tried also to ls /lib/modules/$(uname -r)/kernel/net/ipv4/netfilter and that didn't work because the folder kernel doesn't exist on the OpenVZ either! – GiH May 20 '11 at 14:30
Run lsmod and see what you get. There should be something. You might have to use find to locate the kernel modules (but I do admit that the missing kernel folder is rather strange). – wolfgangsz May 20 '11 at 15:31
Theres nothing... so weird, I just get the columns "Module Size Used by", but nothing under them. This is what I get from running $ modprobe nf_conntrack WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/. FATAL: Module nf_conntrack not found. – GiH May 20 '11 at 17:05
Hmm, that's strange, too. Almost as if this box was upgraded from a much earlier version and the upgrade failed halfway through. Do you have the folder /etc/modprobe.d/? And what is in it? – wolfgangsz May 21 '11 at 10:35
Yes I do, the contents of that folder are: blacklist-ath_pci.conf, blacklist-framebuffer.conf, blacklist.conf, blacklist-firewire.conf, blacklist-watchdog.conf, intel-5300-iwlagn-disable11n.conf... by the way, I think I've figured out the issue, after some research it seems that I can't load kernel modules into an OpenVZ container, my provider needs to do that on the host node and make it available to my container, cause the same kernel is used among all containers. I'm waiting for my provider to respond to my request I'll let you know what happens, thanks for your help! – GiH May 21 '11 at 17:38
If you have other ideas though I'm always open to try things out :) – GiH May 21 '11 at 17:38
I think in this case you need to work with your service provider. – wolfgangsz May 21 '11 at 20:10
User [GiH](http://serverfault.com/users/55302/gih) wanted to add "If on the OpenVZ platform you will not be able to load kernel modules from within your container. Your provider must configure the host node to enable iptables." – Chris S May 24 '11 at 20:25

score 1 · Answer 2 · answered May 19 '11 at 12:25

1

Copy / Paste isn't the appropriate manner

You should use

iptables-save > somefilename.rules

to export the rules in a format compliant with what iptables-restore expects

and then

iptables-restore < somefilename.rules

to proceed with restore

See also the pretty good tutorial on making iptables rules persistant

answered May 19 '11 at 12:25

Open SEO

146
3

thanks, but for some reason when i do iptables-save > somefile.rules, and then I open up the file in vi I see a blank file... what am I doing wrong? – GiH May 19 '11 at 18:22
Figured out what i was doing wrong :), forgot to sudo haha! Ok, so I got the iptables exported and copied them onto the new server, but I still get the same error, now its on a different line (18) because iptables-save compressed the rules and removed all the comments, but it still fails on the COMMIT line – GiH May 20 '11 at 00:19

Why do these 3 rules cause problems for me in iptables? (COMMIT line error)

2 Answers2