2

Hi I'm using Ubuntu 9.04 on a VPS. I'm getting an error if I apply a iptables rule. Here is what I have done.

1.Saved the existing rules

iptables-save > /etc/iptables.up.rules

Created iptables.test.rules and add some rules to it

nano /etc/iptables.test.rulesnano /etc/iptables.test.rules

This is the rules I added

*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 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 22- 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

After editing when I try to apply the rules by 

iptables-restore < /etc/iptables.test.rules

I get the following error

iptables-restore: line 42 failed

Line 42 is COMMIT and I comment that out I get

iptables-restore: COMMIT expected at line 43

I'm not sure what is the problem, it is expecting COMMIT but if COMMIT is there it's giving error. Could it be due to the fact i'm usin a VPS?My provider using OpenVZ for virtualizaton.

Improve this question
1
  • I tried entering each line of the above script manually at the prompt. Most of them resulted in this following error "iptables: No chain/target/match by that name"
    – John Franic
    Jan 9, 2010 at 4:42

5 Answers 5

Reset to default
7

Very old post at this point, but its the top google result so I thought I would update with my solution...

There must be a blank line after COMMIT or iptables-restore will fail with a "no command specified" error at the line COMMIT is on.

Improve this answer
2
  • 1
    That would be if you use an editor that does not automatically add a new line at the end of each line including the last.
    – Alexis Wilke
    Nov 24, 2016 at 0:34
  • THIS. Can't express with words how much pain this mandatory linebreak has caused. Thanks for the answer!
    – Óscar Gómez Alcañiz
    Mar 15, 2020 at 18:40
3

Due to the way iptables-restore works, almost all errors will be reported as being at the COMMIT point. On the odd occasion I have these errors, I go putting COMMITs after each significant line (or, if I'm feeling suspicious, after just the lines I think might be the problem) and seeing which one barfs.

However, a brief inspection of your rules indicates this is your likely problem:

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

The lack of a space between the 22 and the -j is probably the cause of the difficulty. "Attention to detail fail", as the cool kids say.

EDIT: With the added information, I'm going to go out on a limb and say that it's OpenVZ's problem (your VPS provider hasn't given you any iptables quota to add your own rules). I'd find a new VPS provider anyway, myself; VZ is like the Fisher Price toy of virtualisation. It has it's place, in the corporate data centre and the $0.89/decade "price-sensitive" end of the market, but for professional VPS hosting it's an absolute dog.

Improve this answer
5
  • I'm sorry that space I accidentally put while typing here. This is the script I used as reference. articles.slicehost.com/assets/2007/9/4/iptables.txt
    – John Franic
    Jan 9, 2010 at 4:37
  • I tried adding the rules to iptables directly at the prompt. When I ran the second line i.e iptables -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT I got the following error "iptables: No chain/target/match by that name"
    – John Franic
    Jan 9, 2010 at 4:39
  • Did you seriously type that whole thing out by hand? I'm speechless. Who knows how many extra typos you added (I notice that your SSH port typo has morphed). Given that what's in that URL isn't anything like your script, I'd ask that you put exactly what you've got into your question so that we can actually help you. Oh, and you might want to escape that ! on the command line. Bash gets shirty otherwise.
    – womble ♦
    Jan 9, 2010 at 6:51
  • No I didn't type the whole thing, I made some extra spaces while only putting the thing up in serverfault.com, i actually downloaded the script using wget and then made some changes. But can you tell me why this line "iptables -A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT" is giving the error "No chain/target/match by that name"
    – John Franic
    Jan 9, 2010 at 8:30
  • Because you're using an OpenVZ VPS, as per my edited answer.
    – womble ♦
    Jan 9, 2010 at 9:53
1

Perhaps it's failing due to the space character you have before COMMIT?

Improve this answer
2
  • Nah it's not that, the space accidentally came when I entered the code here.What else could this be due to?
    – John Franic
    Jan 8, 2010 at 23:54
  • How do you manage to get a space in the middle of a block of pasted code? If what's in your question isn't what you really have, then edit your question to make it match reality.
    – womble ♦
    Jan 9, 2010 at 2:26
1

An old thread, but also the first one in Google results. Maybe the information below will help somebody who is pulling his hair out trying to figure out why iptables rules aren't restored on boot.

I stumbled upon this issue on Ubuntu 18.04. The netfilter-persistent service failed randomly on boot while working ok when launched manually. Turned out it was conflicting with sshguard service due to systemd trying to load everything in parallel. What helped is to setting ENABLE_FIREWALL=0 in /etc/default/sshguard and then adding sshguard chain and rule manually to /etc/iptables/rules.v4 and /etc/iptables/rules.v6.

Improve this answer
0

I know this is an old post, but it could solve someones problem.

I had the same error, and it was because I have a typo.

The error that was thrown was in "COMMIT", the last line, but in fact was this one:

-A RH-Firewall-1-INPUT -p tcp -m udp --dport 161 -j ACCEPT

The error was that it says in the same line "tcp" and then "udp". So changing that line for:

-A RH-Firewall-1-INPUT -p udp -m udp --dport 161 -j ACCEPT

Solved my problem

Improve this answer

You must log in to answer this question.