Switching off conntrack

Hi,

RH Fedora 6. iptables is used to packet filtering.

The problem is, that conntrack is built in standard Fedora kernel. It
causes that started iptables filters all incoming packets. My server
do not response on any port. It takes a while and then is works
properly. In a couple of minutes it hangs (incoming connections) once
again. Round Robin.

This effect ic caused by conntrack. How to switch conntrack without
kernel recompilation? Is it possible?

Or - How to configure iptables, to make them working properly (without
blocking and unblocking incoming packets)?

Regards,
G.

Hello,

G. a écrit :
>
> RH Fedora 6. iptables is used to packet filtering.
>
> The problem is, that conntrack is built in standard Fedora kernel. It
> causes that started iptables filters all incoming packets. My server
> do not response on any port. It takes a while and then is works
> properly. In a couple of minutes it hangs (incoming connections) once
> again. Round Robin.

Did you check that the conntrack table size is big enough for the number
of connections that your server handles ?

> This effect ic caused by conntrack.

Conntrack alone does not filter anything. It only maintains some
information about packets and connections used by filtering rules and
NAT operation. If the filtering rules do not make use of conntrack-based
matches, conntrack has no effect on packet filtering.

> How to switch conntrack without kernel recompilation? Is it possible?

If your kernel version is at least 2.6.6, you can use the NOTRACK target
in the 'raw' table to disable connection tracking of matching packets.
Matching packets will then have the UNTRACKED state. But, depending on
your iptables ruleset, this may not have the result that you expect.

> Did you check that the conntrack table size is big enough for the number
> of connections that your server handles ?

net.nf_conntrack_max = 65536
net.netfilter.nf_conntrack_max = 65536
net.netfilter.nf_conntrack_count = 2

So... couple of connections and access is blocked.

> > This effect ic caused by conntrack.
>
> Conntrack alone does not filter anything. It only maintains some
> information about packets and connections used by filtering rules and
> NAT operation. If the filtering rules do not make use of conntrack-based
> matches, conntrack has no effect on packet filtering.

Very simple iptables rules:

*filter
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 22 -s 123.123.0.0/16 -j ACCEPT
-A INPUT -p tcp --dport 22 -s 234.234.234.234/32 -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -j DROP
COMMIT

> If your kernel version is at least 2.6.6, you can use the NOTRACK target
> in the 'raw' table to disable connection tracking of matching packets.
> Matching packets will then have the UNTRACKED state. But, depending on
> your iptables ruleset, this may not have the result that you expect.

I've configured *raw table. Effect is the same with a minor change.
Connection blocking take a shorter time. A few minutes. But it still
do not work properly.

G.