Mailing List Archive

On Sun, Jul 29, 2001 at 12:29:29AM -0600, aaz wrote:
> We are going to use iptables on our firewall box. I've been browsing the
> mailing list archives and one particular thread has my interest. Its
> regarding the connection tracking in iptables and that there appears to be
> no way (yet?) of shutting it off per certain rules. Is this still the case
> as of today?

As far as I know, yes.

> If we do not include the ip_conntrack module into the kernel, does netfilter
> basically NOT track connections and our filters just end up working like
> ipchains?

Exactly. You lose NAT in all its variants, and you lose the '-m state'
match in the filter chains. Normal per-packet filter table, and mangle
table stuff should work fine.

> Concern being that some of the posts of people having connections dropped
> because they did not have enough ram to support the number of connections
> they needed as found in /proc/sys/net/ipv4/ip_conntrack_max.

This is reported regularly. However, I have yet to see a machine where
it does affect user service, and have yet to read a report which quantifies
any kind of real user damage done by the mechanism. People are concerned,
but it seems to be more a feeling than a failure which causes the concern.

Most of these long-lived conntracks, at least where I have seen them,
came from oneway port scans (if they are not oneway, your filter table
is too generous :). These oneway connections (not ASSURED, or how the
bit is called nowadays), will be removed preferentially.

> 99% of our traffic will be HTTP to servers behind our firewall that support
> 15-25K visitors a day.
> Our firewall box is a PIII 850, with 256Mb of ram. Does this sound like
> enough?

In this case, 99.999% of all TCP connections through your box will terminate
with proper FIN packets, or terminate with RST after one of your servers
has rebooted. At that point (a bit too early, even), the conntrack entry
is removed. Thus, you'll only need enough conntrack entries for the
concurrently active connections - I'd take "total number of apache processes
on those servers, times four for good measure" as a guess to that number.

Nevertheless, RAM is cheap. Buy some more. You'll run out later when somebody
figures out how to mount a RAM consuming DOS against your firewall, whatever
the path for that is.

regards
Patrick

a followup.

> > If we do not include the ip_conntrack module into the kernel, does
netfilter
> > basically NOT track connections and our filters just end up working like
> > ipchains?
>
> Exactly. You lose NAT in all its variants, and you lose the '-m state'
> match in the filter chains. Normal per-packet filter table, and mangle
> table stuff should work fine.

What is generally better performing? Not loading ip_conntrack and just using
ipchains like filters, OR using ip_conntrack and the state module in rules?

> > Exactly. You lose NAT in all its variants, and you lose the '-m state'
> > match in the filter chains. Normal per-packet filter table, and mangle
> > table stuff should work fine.
>
> What is generally better performing? Not loading ip_conntrack and just using
> ipchains like filters, OR using ip_conntrack and the state module in rules?

I strongly doubt that you could tell the difference for most real life
workloads and ruleset complexity. However, doing a proper comparison
appears impossible: how would you implement the "same semantics" with
both models? Without equality in semantics, performance comparisons
become somewhat apples to oranges.

The best you can do - and only you can do that - is implement the policy
you want both ways, and run comparisons in your real work environment.
If you use kernel profiling, and run one or the other variant each for
one week, you should get pretty reliable results. I'd love to see them,
especially if they show that my first assumption in the first paragraph
is wrong.

best regards
Patrick