topic Re: iptable question in Operating System - Linux

iptable question

joe_91 — Fri, 06 May 2011 00:24:21 GMT

We have on a RHEL4/RHEL5 servers ip_conntrack module loaded and causing some network resources issues. My question is how could ip_conntrack module be loaded when we have disabled iptables? Could it be automatically loaded by any application? if so how could you look?

Thanks

Joe.

Re: iptable question

joe_91 — Fri, 06 May 2011 13:07:08 GMT

I checked the following

/etc/init.d/iptables status
Firewall is stopped.

Thanks

Joe.

Re: iptable question

Matti_Kurkela — Fri, 06 May 2011 17:16:33 GMT

RHEL's /etc/init.d/iptables is just one way to configure iptables firewalls - there might be a custom script or even a complete firewall management application that has applied a set of firewall settings completely separately from /etc/init.d/iptables.

The conntrack module may have been loaded automatically when required by some iptables rule that has been removed since then: it won't auto-unload when it's no longer needed.

What is the output of following commands:

lsmod | grep conntrack
iptables -L -vn
iptables -L -vnt nat
iptables -L -vnt mangle

If the "Used by" value of the conntrack module is 0 in the lsmod listing, the module is currently unused and can safely be rmmod'd.

MK

Re: iptable question

joe_91 — Fri, 06 May 2011 20:11:37 GMT

Here are the ouputs..

/etc/init.d/iptables status
Firewall is stopped.

lsmod|grep conn
ip_conntrack 54297 1 iptable_nat

(so there is one connection)

When i did /etc/init.d/iptables stop and then did a lsmod|grep ip_conn the conntrack was gone. Does it mean there was some old connection sitting there? Also when i did cat /proc/net/ip_conntrack there was time_wait in those connections, so is it safe to assume that may some old connections or leftovers from from some rules?? Since there was one connection from lsmod output how do we find out what that is??

Thanks

Joe.

Re: iptable question

joe_91 — Fri, 06 May 2011 20:18:31 GMT

Here are the other outputs

#iptables -L -vn
Chain INPUT (policy ACCEPT 508 packets, 44674 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 432 packets, 38412 bytes)
pkts bytes target prot opt in out source destination
# iptables -L -vnt nat
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

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

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

# iptables -L -vnt mangle
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 0 packets, 0 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 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

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

Thanks

Joe

Re: iptable question

Matti_Kurkela — Sat, 07 May 2011 06:45:00 GMT

> lsmod|grep conn
> ip_conntrack 54297 1 iptable_nat

> (so there is one connection)

Not necessarily one connection, but one other module (specifically iptable_nat) using the services of the ip_conntrack module.

/proc/net/ip_conntrack is *exactly* the right place to look: it lists the connections currently handled by the ip_conntrack module.

Perhaps there was one or more existing NATted connections, or old NATted connections waiting for their TIME_WAIT timers to expire when you originally disabled iptables, so the module could not be removed at that time.

Later, when you ran "/etc/init.d/iptables stop" again, those connections apparently had all reached a closed state, and both the iptable_nat and ip_conntrack modules could allow themselves to be removed without any risk of network traffic disruption.

MK