Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Hi could could anyone help me understand why line 15 is failing supposedly in my iptables file. I'm using CentOS 6.

When I try to restart iptables service, get the following:

[root@dbserver ~]# service iptables restart
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules: iptables-restore: line 15 failed
                                                           [FAILED]

My iptables file looks like:

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT
#-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m udp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.1/254 -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT

I'm only really trying to allow access to the machine from the local network presently.

Any help would be much appreciated. Thanks.

EDIT:

As per first answer, have moved COMMIT to end of file, however still receiving errors...

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m udp -p tcp --dport 53 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 443 -j ACCEPT
-A RH-Firewall-1-INPUT -m tcp -p tcp --dport 25 -j ACCEPT
-A RH-Firewall-1-INPUT -s 192.168.1.0/255 -m state --state NEW -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -p tcp --dport 21 -j ACCEPT
COMMIT

Error:

[root@dbserver ~]# service iptables restart
iptables: Flushing firewall rules:                         [  OK  ]
iptables: Setting chains to policy ACCEPT: filter          [  OK  ]
iptables: Unloading modules:                               [  OK  ]
iptables: Applying firewall rules: iptables-restore: line 13 failed
                                                           [FAILED]
share|improve this question
    
@MadHatter, yes good point. Some of the answers however, although full of really good info, weren't spot on so didn't want to confuse other users having same problem –  Larry B Oct 2 '12 at 10:56
    
192.168.1.1/254 looks wrong –  mtm Oct 2 '12 at 11:07

5 Answers 5

up vote 4 down vote accepted

Simple -- you need to move your COMMIT down to the end of the file.

COMMIT tells iptables that you've finished your declaration and want to send your configuration to the kernel. It ends your declaration. You're telling iptables to COMMIT, and then you're giving new rules without a new declaration, hence your error.

Edit to include contents of comment downwind:

Here's an updated and working (not necessarily optimal) version of your config: http://gist.github.com/3818123. I'll summarize some of the issues:

  1. Your input chain, RH-Firewall-1-INPUT, doesn't exist. Are you copying and pasting from somewhere else?
  2. Some of your rules fell after your default-reject rules. Even if the syntax took, the rules wouldn't work.
  3. 192.168.1.1/254 isn't even close to valid CIDR addressing. Did you mean 192.168.1.0/24?
  4. You have -A RH-Firewall-1-INPUT -m udp -p tcp, which doesn't make any sense -- I'm assuming you mean -A INPUT -m udp -p udp.
share|improve this answer
    
Thanks, i've move commit to the end but still receive error: [root@dbserver ~]# service iptables restart iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] iptables: Applying firewall rules: iptables-restore: line 13 failed [FAILED] Any thoughts? cheers –  Larry B Oct 2 '12 at 10:37
    
Hoo boy, looking this over more carefully, you've got probably half a dozen mistakes on here. I'll post an updated version to Gist in a second, but does system-config-securitylevel-tui do what you need it to do? It's a lot simpler than mucking with rules directly. –  jgoldschrafe Oct 2 '12 at 10:43
    
I've updated the answer to address some of the other issues with the configuration. –  jgoldschrafe Oct 2 '12 at 10:59
    
Thanks for all your input, just about to test. These believe it or not were from authoritative looking article –  Larry B Oct 2 '12 at 11:01
    
Success! Much appreciated! –  Larry B Oct 2 '12 at 11:12

Try putting the two lines

-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

at the end of the file before COMMIT.

share|improve this answer
    
Sorry, how does this relate to the OP's question? –  MadHatter Jan 15 at 10:10

Yeah dude, /24 ... slash notation. Google slash notation conversion. Looking at your first example table made me gasp.

I've been told the same thing many times over the years, but you are in over your head. How does one get to manually editing iptables rules without being aware of slash notation? It's used pretty much ... everywhere.

And like everyone said, important or not, it's a server -- it's not a place to play. If security isn't important and it's behind a firewall and not exposed to the internet, turn iptables off ('#service iptables stop; #chkconfig iptables off') ... and play with it at home.

This way, when stuff doesn't work, you don't have to wonder why.

share|improve this answer
1  
Welcome to Server Fault. This is not a forum; any answers should actually answer the question. See our About page and FAQ to learn how we are different from other sites. –  Michael Hampton May 23 '13 at 4:48

In general it pays to add rules via iptables and then dump them to a file with iptables-save in case you want to use to load them again via iptables-restore for example when your system restarts because quite simply iptables-save knows its own prerequisites better than you.

share|improve this answer

In addition to the COMMIT problem, as mentioned by jgoldschrafe, you're trying to add lines to a rule that doesn't exist (RH-Firewall-1-INPUT).

You will need to add a line

:RH-Firewall-1-INPUT - [0:0]

immediately below

:OUTPUT ACCEPT [0:0]

which will declare the chain, thus allowing you to add rules to it. But the chain will still have no effect, as there's nothing magic about the name, and nothing in the three main chains (INPUT,OUTPUT, and FORWARD) sends any packets to it. Certainly you can add a rule to the INPUT chain to send traffic to your new chain, but - and please don't take this the wrong way - I do note that it says at the top of that file

Manual customization of this file is not recommended.

That's there for a reason. By all means do ignore that, and edit it, but you may make some pretty big holes in your system's security or availability while you're learning to get it right.

Edit: I suspect the problem with line 19 is the address range specified as 192.168.1.0/255, which is not valid. If you want to indicate all addresses between 192.168.1.0 and 192.168.1.255, you need 192.168.1.0/24.

I do beg your pardon, but you're really not coming across as someone who knows a lot about firewalling and networks, and - assuming that this is a server you're maintaining professionally - it may not be the best place to learn this stuff.

share|improve this answer
    
Thanks for this, this still produces an error unfortuantely. iptables: Applying firewall rules: iptables-restore v1.4.7: invalid mask 254' specified Error occurred at line: 19 Try iptables-restore -h' or 'iptables-restore --help' for more information. [FAILED] Any thoughts? cheers –  Larry B Oct 2 '12 at 10:57
    
Thank you, the "/" denoting a range did throw me a little. It's simply a database server for use on our local network and not one holding the location of the Queens private reserve of Toblerones or anything as sensitive, so just an opportunity to learn really. cheers. –  Larry B Oct 2 '12 at 11:19
    
Mmmmmm, National Toblerone Reserve; my kind of Swiss banking! And the slash doesn't denote a range, it denotes a mask, aka netmask. –  MadHatter Oct 2 '12 at 11:23
    
Ah! Nice one ;) –  Larry B Oct 2 '12 at 11:38

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.