Unable to apply firewall rules to new cluster node [#35842]

Submitted by ChrisBlackwell on Wed, 01/14/2015 - 03:21

I'm migrating to some new hardware and have added a new physical box into my cloudmin setup. I have the managed boxes added in the cluster settings for the iptables module on the cloudmin master, so the rules get applied cluster-wide, this has been working.

All the boxes are Centos 6.6, fully updated.

When i click apply on the master i get this error

Failed to apply configuration : Error from new-box.example.com :
iptables: Setting chains to policy ACCEPT: filter mangle nat [  OK  ]
iptables: Flushing firewall rules: [  OK  ]
iptables: Unloading modules: [  OK  ]
iptables: Applying firewall rules: iptables-restore v1.4.7: Can't set policy `INPUT' on `ACCEPT' line 34: Bad built-in chain name

Here's the content of /etc/sysconfig/iptables on the new box after an attempted sync. If i comment out line 34 this will then work

# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:FORWARD DROP [0:0]
:INPUT DROP [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 -p tcp -m tcp -m state --dport 20:21 --state NEW -j ACCEPT
-A INPUT -p tcp -m state -m tcp --dport 22 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 25 --state NEW -j ACCEPT
-A INPUT -p udp -m udp -m state --dport 53 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 53 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 80 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 110 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 443 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 2222 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 3306 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 9000 --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp -m state --dport 10000:10010 --state NEW -j ACCEPT
COMMIT
# Generated by webmin
*mangle
:FORWARD ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed
# Generated by webmin
*nat
:INPUT ACCEPT [0:0]    # <-- this line causes the problem
:OUTPUT ACCEPT [0:0]
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed

All the boxes are uptodate and running iptables 1.4.7

Status:

Active

Comments

Submitted by JamieCameron on Wed, 01/14/2015 - 22:44 Comment #1

That is odd ... on the master system, does the /etc/sysconfig/iptables file contain that problem line?

The sync process should just copy the whole file over to the replicas.

Submitted by JamieCameron on Wed, 01/14/2015 - 22:45 Comment #2

Submitted by ChrisBlackwell on Thu, 01/15/2015 - 03:18 Comment #3

Yes the files are identical. To check I have manually saved the firewall rules and copied them over.

[root@master ~]# iptables-save > iptables
[root@master ~]# iptables-restore < iptables
[root@master ~]# scp iptables root@newbox:/root

[root@newbox ~]# iptables-restore < iptables
iptables-restore v1.4.7: Can't set policy `INPUT' on `ACCEPT' line 10: Bad built-in chain name

The iptables script is slightly different, so the error has moved to line 10

# Generated by iptables-save v1.4.7 on Wed Jan 14 09:16:00 2015
*raw
:PREROUTING ACCEPT [5547:1744469]
:OUTPUT ACCEPT [4889:1256190]
COMMIT
# Completed on Wed Jan 14 09:16:00 2015
# Generated by iptables-save v1.4.7 on Wed Jan 14 09:16:00 2015
*nat
:PREROUTING ACCEPT [1013:34437]
:INPUT ACCEPT [682:23388]
:OUTPUT ACCEPT [416:53261]
:POSTROUTING ACCEPT [416:53261]
COMMIT
# Completed on Wed Jan 14 09:16:00 2015
# Generated by iptables-save v1.4.7 on Wed Jan 14 09:16:00 2015
*mangle
:PREROUTING ACCEPT [5547:1744469]
:INPUT ACCEPT [5228:1734216]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4889:1256190]
:POSTROUTING ACCEPT [4889:1256190]
COMMIT
# Completed on Wed Jan 14 09:16:00 2015
# Generated by iptables-save v1.4.7 on Wed Jan 14 09:16:00 2015
*filter
:INPUT DROP [51:2508]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [4889:1256190]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20:21 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 2222 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3306 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 9000 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10000:10010 -m state --state NEW -j ACCEPT
COMMIT
# Completed on Wed Jan 14 09:16:00 2015

The only thing i can think of that might be causing an issue is different kernels. Whilst both master and newbox are running Centos 6.6 and fully updated. The master is a baremetal machine running my hosting companies Centos image, which i think has a different kernel, and newbox is a vm running a stock kernel

[root@master ~]# uname -a
Linux master  2.6.38.2-grsec-xxxx-grs-ipv6-64 #2 SMP Thu Aug 25 16:40:22 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

[root@newbox ~]# uname -a
Linux newbox  2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Submitted by JamieCameron on Thu, 01/15/2015 - 13:41 Comment #4

I guess what I'm interested in is how that line came into being in the first place, since it is invalid.

Were these firewall rules entirely created by Webmin?

Submitted by ChrisBlackwell on Tue, 01/20/2015 - 10:30 Comment #5

yep, these rules were entirely created by the webmin module

Submitted by JamieCameron on Tue, 01/20/2015 - 22:06 Comment #6

So if you remove that problem line, does Webmin re-create it when you edit rules?

Submitted by ChrisBlackwell on Wed, 01/21/2015 - 04:05 Comment #7

yes it does, and apparently it is behaving correctly. as i suspected, its down to the kernel version, see http://serverfault.com/questions/245564/iptables-built-in-input-chain-in...

it appear the NAT INPUT chain was added in kernel 2.6.35. My Cloudmin Master is running kernel 2.6.38 but the node that fails when applying the iptables rule is on 2.6.32. Don't ask me why my 4yr old box has a newer kernel than a fully updated new install.. but apparently it does

As this is all part of a migration (from bare metal to vm's) i'm not going to worry any more on this. eventually all my nodes will be on the same kernel so this will go away.

However you may want to think on whether webmin/cloudmin needs to do some sanity checking to prevent this error from occuring

Submitted by JamieCameron on Wed, 01/21/2015 - 21:24 Comment #8

Ahh .. maybe that explains it. Webmin just assumes that the same set of rules is usable on all systems in the cluster.