[SOLVED] Firewall will not stay disabled after reboot

quasi3 · 08-31-2009, 03:24 PM

CentOS 5.2 64bit
2.6.18-92.el5xen

Trying to disable the firewall on a system. The kickstart file used for install had firewall disabled.
Firewall comes up on boot.

Have tried the following commands in several different recommended orders:
chkconfig --del iptables
service iptables save
service iptables stop

Firewall still comes up on reboot.

Have manually deleted /etc/sysconfig/iptables-config
Firewall still comes up on reboot.

If I reboot to runlevel 5 and look at the status of the firewall in the OS gui it says that the firewall is disabled. But, if I check the status from the command line it is up and the software we are testing fails because it needs to be down.

Have used the same kickstart file on a few other servers without this problem however these were 32 bit.

Is there a bug with 64 bit CentOS 5.2 that does not allow you to permanently shut off the firewall?

MensaWater · 08-31-2009, 03:31 PM

You shouldn't do "del" you should do "off":

Quote:

--del name
The service is removed from chkconfig management, and any sym-
bolic links in /etc/rc[0-6].d which pertain to it are removed.

Note that future package installs for this service may run chk-
config --add, which will re-add such links. To disable a ser-
vice, run chkconfig name off.

The Netfilter (iptables) firewall is built into the kernel. You can stop it however, you'll always see at a minimum the following there when you run iptables -L:

Code:

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

The above output means it is essentially OFF and is NOT your problem because it is not blocking anything.

Have you checked your SELinux setting:
getenforce
This should show Enforcing, Permissive or Disabled. If it is Enforcing you may have a context issue somewhere. You can change enforcement level with the setenforce command.

Also RHEL5/CentOS5 have tcpwrappers built in. You might want to verify you haven't put restrictions in /etc/hosts.allow, /etc/hosts.deny that are causing your problems.

quasi3 · 08-31-2009, 03:47 PM

Have tried:
chkconfig iptables off
as well, forgot to include in the list.

getenforce shows disabled.

Nothing in hosts.allow or hosts.deny

MensaWater · 08-31-2009, 03:52 PM

What do you see when you run "iptables -L"?

quasi3 · 08-31-2009, 04:12 PM

Before reboot:
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

After reboot:
iptables -L

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

fordeck · 08-31-2009, 04:35 PM

So if you run the following command:

Code:

[root@fs2 ~]# chkconfig --list | grep iptable
iptables       	0:off	1:off	2:on	3:on	4:on	5:on	6:off

The above output shows that in runlevels 2-5 iptables is on. If you then run the following command:

Code:

chkconfig iptables off

Then check it again

Code:

[root@fs2 ~]# chkconfig --list | grep iptable
iptables       	0:off	1:off	2:off	3:off	4:off	5:off	6:off

Now with that change the next time you boot, iptables will not be enabled. Try these steps and let us know after the reboot if iptables is then showing the following:

Code:

[root@fs2 ~]# 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

Regards,

Fordeck

MensaWater · 09-01-2009, 08:08 AM

Since it's built into the kernel running the the delete might be your issue.

Try running "chkconfig --add iptables" to add it back then run the "chkconfig iptables off" to turn it off in all run levels.

quasi3 · 09-01-2009, 10:09 AM

As it turns out I'm seeing this behavior on some other machines including 32bit CentOS 5.2 so that theory gone.

fordeck,
Immediately after reboot if I run 'chkconfig --list | grep iptable':

chkconfig --list | grep iptable
iptables 0;off 1;off 2;off 3;off 4;off 5;off 6;off

If I then run 'iptables -L':
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:domain
ACCEPT tcp -- anywhere anywhere tcp dpt:domain
ACCEPT udp -- anywhere anywhere udp dpt:bootps
ACCEPT tcp -- anywhere anywhere tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere 192.168.122.0/24 state RELATED,ESTABLISHED
ACCEPT all -- 192.168.122.0/24 anywhere
ACCEPT all -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable
REJECT all -- anywhere anywhere reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Then if I run 'chkconfig iptables off' and then 'chkconfig --list | grep iptable'
chkconfig --list | grep iptable
iptables 0;off 1;off 2;off 3;off 4;off 5;off 6;off

I still get the same result when I run 'iptables -L'

jlightner,
I tried "chkconfig --add iptables" and "chkconfig iptables off" with no success.

MensaWater · 09-01-2009, 11:11 AM

It does it to me too on my 32 Bit CentOS 5.3 install when I tested just now.

However, I think I know why it did it to me and likely why it did it to you.

I'm running the Xen kernel. (uname -r shows 2.6.18-128.4.1.el5xen). You are running a Xen kernel as well according to your first post.

When I run "xm list" it shows my Dom0 (master domain) there.

In /etc/xen/scripts there are scripts that deal with iptables so I believe it is setting up iptables on the Dom0 to allow for interaction with the Xen guests (which is why you see the local LAN 192.168.x.x stuff in your iptables output).

I guess you could muck around with the scripts to disable this stuff or just live with it. If you don't intend to run Xen guests you could even downgrade to the non-xen kernel.

quasi3 · 09-01-2009, 03:52 PM

Xen issue got me on the right track. It was actually libvirtd.

ran:
'yum erase libvirt'

Fixed issue.
Probably could have just disabled it. But had a previous issue with libvirt so dont need it.

Thanks for all your input.

MensaWater · 09-01-2009, 04:02 PM

That's it. Thanks for posting your resolution.

There is a libvirtd service in /etc/init.d.

When I stop iptables and libvirtd then restart libvirtd (service libvertd start) It populated iptables so is clearly the culprit.

So running "chkconfig libvirtd off" (and chkconfig iptables off) would probably have resolved your issue.

jefro · 09-01-2009, 05:25 PM

Why would you turn off firewall?

quasi3 · 09-01-2009, 10:40 PM

Jefro,
I work in R&D for a telecom company. We do a lot of load tests with several different protocols and different third party telecom software. We often run into problems with firewalls on the servers. In this particular issue we would not start experiencing errors until quite some time in to a load test which makes it problematic to troubleshoot the firewall issue. All of our servers are behind a hardware firewall anyway so the easiest thing for us to do is to just disable the software firewall on our test boxes.