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.

I'm having an issue with IPtables on a CentOS 5.6 machine which was previously working fine, i'm not entirely sure when this began happening as i only noticed the problem when i came to allow a new IP on a port.

Basically, when i attempt to stop, start or restart i get the following:

Flushing firewall rules: [  OK  ]
Setting chains to policy ACCEPT: security raw nat mangle filter [FAILED]
Unloading iptables modules: [  OK  ]

For some reason, no matter what i do i can't reconfigure the rules. I've tried going so far as to uninstall IPtables completely (through yum), but even after a system restart it was still only allowing connections to the ports that were open before the problem began, and filtering everything else.

I'm really at my wits end, iptables status shows completely empty chains, but still no joy as far as external connections.

Any ideas would be appreciated. If you'd like me to provide any more information please let me know.

Thanks in advance,
Sam.

EDIT: Contents of /etc/sysconfig/iptables (it's basically empty due to having removed and reinstalled iptables).

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

EDIT 2:

If i run /etc/init.d/iptables stop i get:

Flushing firewall rules: [  OK  ]
Setting chains to policy ACCEPT: security raw nat mangle filter [FAILED]
Unloading iptables modules: [  OK  ]

And the empty rules:

$ iptables -L -n -v
Chain INPUT (policy ACCEPT 81 packets, 6575 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 72 packets, 4133 bytes)
 pkts bytes target     prot opt in     out     source               destination

But it still blocks and filters the ports.

Similarly, starting results in:

/etc/init.d/iptables start
Flushing firewall rules: [  OK  ]
Setting chains to policy ACCEPT: security raw nat mangle filter [FAILED]
Unloading iptables modules: [  OK  ]
Applying iptables firewall rules: [  OK  ]

iptables -L -n -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  207 54155 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 reject-with tcp-reset 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    4   228 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
    2   116 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:110 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:143 
    1    52 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:993 
    2   128 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:995 
    0     0 ACCEPT     tcp  --  *      *       -sanitized-          0.0.0.0/0           tcp dpt:22 
    0     0 ACCEPT     tcp  --  *      *       192.168.0.0/16       0.0.0.0/0           tcp dpt:22 
    0     0 DROP       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 code 0 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 reject-with tcp-reset 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
    0     0 ACCEPT     all  --  lo     lo      0.0.0.0/0            0.0.0.0/0           
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  158 25662 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 REJECT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp flags:!0x17/0x02 reject-with tcp-reset 
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           state INVALID 
    0     0 ACCEPT     all  --  *      lo      0.0.0.0/0            0.0.0.0/0           
   33  2351 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

But i still can't connect on SSH port 22 (i'm otherwise using a serial console).

share|improve this question
    
Can you edit your question with the contents of your (appropriately sanitized) /etc/sysconfig/iptables file please. –  Iain Jul 11 '11 at 10:43
    
No worries, done. –  Sam Jul 11 '11 at 10:48
    
Could we also directly see the live ruleset, with iptables -L -n -v? –  MadHatter Jul 11 '11 at 11:11
    
Added more info re live rulesets (stopped and started). –  Sam Jul 11 '11 at 11:27

4 Answers 4

This thread had a solution that worked for me: http://forum.linode.com/viewtopic.php?t=6981&postdays=0&postorder=asc&start=0

The solution is to add the following lines to /etc/init.d/iptables

    echo -n $"${IPTABLES}: Setting chains to policy $policy: "
    ret=0
    for i in $tables; do
        echo -n "$i "
        case "$i" in
+           security)
+               $IPTABLES -t filter -P INPUT $policy \
+                   && $IPTABLES -t filter -P OUTPUT $policy \
+                   && $IPTABLES -t filter -P FORWARD $policy \
+                   || let ret+=1
+               ;;
            raw)
                $IPTABLES -t raw -P PREROUTING $policy \
                    && $IPTABLES -t raw -P OUTPUT $policy \
                    || let ret+=1
                ;;
share|improve this answer

Are you running this on Linode (or other VPS)? I ask this because, searching for "Setting chains to policy ACCEPT: security raw nat mangle filter" in Google, I found the following reference:

Linode.com Forum :: View topic - IPTables
http://www.linode.com/forums/archive/o_t/t_3930/iptables.html

In that discussion, the relevant message is this one by user "troublshootr", that also mentions CentOS (I bolded what it seems to me the solution part of the reply):

I asked the same question and it wasn't really answered. This is what I received from support:

" The issue is that the "Latest 2.6 Paravirt" kernel has a "security" chain and iptables doesn't know how to handle it. Usually switching to the "Latest 2.6 Stable" kernel resolves the issue without any further tweaking of the iptables init script (it often just ignores that chain and starts normally). Our builds team is indeed aware of this problem, however I do not have an ETA on if/when it will be resolved. It is perfectly fine to continue using our "Latest 2.6 Stable" kernel -- this kernel was actually the default selection for CentOS deployments until recently. No applications, with the exception of iptables, will operate differently when using the stable kernel. "

Does this help?

share|improve this answer
    
Thanks for your reply, however unfortunately i'm not with Linode. :-( I also found that forum thread (searching for "Setting chains to policy ACCEPT: security raw nat mangle filter [FAILED]" really doesn't turn up many results :-P), and their suggestion of switching to an alternative kernel doesn't help in my case. This particular server is with 1&1 (who are awful, i won't be with them for much longer), but for the time being i'm really trying to get this machine working again. –  Sam Jul 11 '11 at 11:16
    
if you do the flush manually, does all 3 give you the same result? –  Stokkeland Jul 11 '11 at 11:49
    
e.g iptables -F INPUT –  Stokkeland Jul 11 '11 at 11:49
    
Flushing seems to have no effect at all. :-( –  Sam Jul 12 '11 at 10:44

In the error message, each of the items listed is a separate iptables table. Individual tables are supported by kernel modules:

  • the iptable_raw module will, when loaded, register a hook that will be called before any other Netfilter hook. It provides a table called raw that can be used to filter packets before they reach more memory-demanding operations such as Connection Tracking.
  • the iptable_mangle module registers a hook and mangle table to run after Connection Tracking (but still before any other table), so that modifications can be made to the packet that may influence further rules such as NAT or filtering.
  • the iptable_nat module registers two hooks: DNAT-based transformations are applied before the filter hook, SNAT-based transformations are applied afterwards. The nat table that is made available to iptables is merely a “configuration database” for NAT mappings only, and not intended for filtering of any kind.
  • the iptable_filter module registers the filter table, used for general-purpose filtering (firewalling).

The security table is relatively new, and it's possible the kernel you're using does not have it compiled in. You can confirm this by running iptables -t <table> -L; i.e.:

adam@adamc: $ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

adam@adamc: $ sudo iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         

The real trick is, I have no idea how to tell CentOS to not bother to load the security table. Poking around in the init script may reveal a configuration file where those lines are listed; failing that, you can edit the init script directly to remove any tables you don't have installed.

share|improve this answer
    
Thanks for this response. I tried listing the tables as above, and it seems the kernel does have all of them (including security), however the init script didn't have a section for security. After a little digging, it seems that script pulls the table names from /proc/net/ip_table_names, so i edited the script to add a section for security, which actually "fixed" that (ie. no failure message on stop/start/restart), however unfortunately it still seems that the new rules aren't applied! I'm thinking it's an issue with the 1&1 kernel that came with the OS image... :-S –  Sam Jul 12 '11 at 10:43

Are you by any chance running Webmin or another control panel on this server?

I had the same problem with a CentOS 5.6 server where everything I did with iptables through the command line was flushed after a reboot; only the rules I entered through the interface in Webmin would stick.

share|improve this answer
    
The server does (unfortunately) run Plesk, however the old filter rules are being preserved through reboots, and even with iptables uninstalled. No new rules are being applied at all, despite numerous attempts. –  Sam Jul 12 '11 at 10:45
    
Seems odd that the old rules would be preserved even with iptables uninstalled. Plesk may be running its own copy of iptables. I haven't used Plesk in a while, but I'm going to guess that when you say, "No new rules are being applied at all, despite numerous attempts" you have tried adding rules through Plesk? –  tfitzgerald Jul 12 '11 at 14:51
    
Unfortunately i can't even get to Plesk - the port on which it runs was filtered for everything but our office IP. However, we recently changed ISPs so our IP has changed. We had added this to the configuration in Plesk (which does just create a script for IPtables) prior to the change, but hadn't noticed this issue and that the rules hadn't gone into effect until after the switchover. –  Sam Jul 12 '11 at 15:44

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.