disabling conntrack ...

Derick Anderson danderson at vikus.com
Fri Aug 26 18:37:51 CEST 2005

Someone else will probably jump on this who knows more than I do...

1. Going to assume that your firewall is set up with at least two NICs
and thus is a router or a bridge of some kind. What this means is that
the packets you care about most (i.e., those going through the firewall)
are going through the FORWARD chain in the filter table, not INPUT and
OUTPUT. You are accepting all FORWARD traffic. You are not filtering on
it at all (unless this is being done in mangle or nat tables...?). That
would explain the hideous number of connections you are getting. All
those filtering rules ought to be using the FORWARD chain (i.e., -A
FORWARD -j MY_RULE-FORWARD). You will still need some rules for INPUT
like allowing SSH and RELATED,ESTABLISHED connections.

2. Your INPUT and FORWARD chains should have a default DROP policy.
Whether the OUTPUT chain should is a matter of great debate. For a
beginner I'd say use ACCEPT for OUTPUT. The default DROP policy does the
same thing that your -j REJECT statements are doing, except that it
simply drops the connection, which reduces the load on your system by
not sending "this port closed" messages to millions of zombie machines.

3. Your stateful filtering needs a lot of work. Things are working
because you are allowing any connection higher than port 1023 (for
INPUT; FORWARD accepts anything). What you need is something like this:


as your first FORWARD rule. Why? The vast majority of legitimate packets
that will traverse through your system (provided you are using
connection tracking) will be accepted by this rule. Because a packet
will traverse a chain until it hits a rule that it matches, for
performance reasons you should have the most "popular rules" as high as
possible in the chain. Next you should only accept NEW packets into your
specific ports. You can either create a custom chain for this or append
'-m state --state NEW' to the rest of your FORWARD rules. It's to your
advantage (both for typing and firewall performance) to create a custom


-A FORWARD -m state --state NEW -j MY_RULE
-A MY_RULE-FORWARD -p tcp ...[accept port whatever]...

4. Since you weren't using FORWARD you aren't validating which packets
are inbound and which are outbound. Some people do this with just source
or destination addresses; I prefer to do it with interfaces as well. My
(and others I'm sure) way requires knowing which interface is
Internet-facing and which is internally-facing but it ties the packet to
a physical source rather than a potentially faked virtual one. Let's say
that eth0 is your Internet-facing interface and eth1 is your
internal-facing interface. Your filtering rules should look something
like this:

# For allowing inbound HTTP to a specific server.
-A MY_RULE-FORWARD -p tcp -i eth0 -o eth1 -d --dport 80 -j

# For allowing outbound HTTP to the Internet
-A MY_RULE-FORWARD -p tcp -i eth1 -o eth0 --dport 80 -j ACCEPT

5. Just allowing a specific port without qualifying what IPs have a
valid server for it will still let in a ton of unnecessary packets. Your
mail server doesn't have a web server? Then don't allow inbound HTTP to

I suggest a thorough reading of Oskar Andreasson's iptables tutorial at
http://iptables-tutorial.frozentux.net/iptables-tutorial.html which will
help to enlighten you from a very technical perspective. This tutorial
was the difference for me between hacking random scripts I found on the
Internet and actually understanding iptables.

Derick Anderson

> -----Original Message-----
> From: netfilter-bounces at lists.netfilter.org 
> [mailto:netfilter-bounces at lists.netfilter.org] On Behalf Of 
> Kerryn Wood
> Sent: Friday, August 26, 2005 10:42 AM
> To: netfilter at lists.netfilter.org
> Subject: RE: disabling conntrack ...
> *bows head in shame*
> I'm relatively new to iptables (landing the role of 
> administrator because nobody else wanted it!) so was trying 
> different options, albeit the wrong ones :)
> The scenario is this:
> I'm running a machine that's generating a HUGE amount of traffic. 
> I was seeing many of the "ip_conntrack: table full, dropping packet"
> errors and this I suspected was causing major problems with 
> the software I was running on the machine. (It looks like it 
> may be because the machine at the time was working on a 
> network in the US so timeouts (etc
> ...) were taking longer.) I've increased the hashsize 
> substantially because as far as I understand the default 
> hashsize is configured (max) for 2GB of RAM where the machine 
> is running with 12GB. The error messages just took longer to appear.
> As the dropping packets are currently the top of the "what's 
> causing our problems" list I was (mistakenly apparently :D) 
> investigating disabling connection tracking (we're not 
> NAT'd), but based on your response I'm guessing it was the 
> wrong way to go about it!
> I think the rules file that iptables-restore was trying to 
> read is /etc/sysconfig/iptables which I've included at the 
> end of the mail. Line
> 57 (I've removed all the superfluous documentation lines) is 
> the COMMIT.
> Thanks for the help,
> Kerryn
> *filter
> :MYRULE-INPUT - [0:0]
> -A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,PSH FIN,SYN,PSH 
> -j LOG -A OUTPUT -p tcp -m tcp --tcp-flags FIN,SYN,PSH 
> FIN,SYN,PSH -j REJECT --reject-with icmp-port-unreachable
> -A MYRULE-INPUT -m state --state NEW -m tcp -p tcp --dport 
> 199 -j ACCEPT -A MYRULE-INPUT -m state --state NEW -m udp -p 
> udp --dport 161 -j ACCEPT -A MYRULE-INPUT -p udp -m udp 
> --sport 123 --dport 123 -m state --state RELATED,ESTABLISHED 
> -j ACCEPT -A MYRULE-INPUT -m state --state NEW -m tcp -p tcp 
> --dport 80 -j ACCEPT -A MYRULE-INPUT -m state --state NEW -m 
> tcp -p tcp --dport 443 -j ACCEPT -A MYRULE-INPUT -m state 
> --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A 
> -A MYRULE-INPUT -p tcp -m tcp --dport 0:1023 --syn -j REJECT 
> -A MYRULE-INPUT -p tcp -m tcp --dport 2049 --syn -j REJECT -A 
> MYRULE-INPUT -p udp -m udp --dport 0:1023 -j REJECT -A 
> MYRULE-INPUT -p udp -m udp --dport 2049 -j REJECT -A 
> MYRULE-INPUT -p tcp -m tcp --dport 6000:6009 --syn -j REJECT 
> -A MYRULE-INPUT -p tcp -m tcp --dport 7100 --syn -j REJECT
> -----Original Message-----
> From: netfilter-bounces at lists.netfilter.org
> [mailto:netfilter-bounces at lists.netfilter.org] On Behalf Of /dev/rob0
> Sent: 26 August 2005 14:17
> To: netfilter at lists.netfilter.org
> Subject: Re: disabling conntrack ...
> On Friday 2005-August-26 07:20, Kerryn Wood wrote:
> > I need to disable connection tracking and, although I've seen an old
> Oh my, what a strange need this is! Tell us why you think you 
> need it, and we can answer your questions more effectively 
> (likely explaining why you are wrong.)
> > I *think* I've removed all the connection tracking modules from 
> > /lib/modules/<kernel version>/kernel/net/ipv4/netfilter/ (I removed 
> > all ip_conntrack* files).
> Ouch. This is a reckless approach to system administration. 
> Do not delete files whose purpose you do not understand.
> > When I try and start iptables again I get an error from 
> > iptables-restore. The error message is: "line 57 failed".
> The rule on line 57 of your iptables-restore rules (check 
> your OS documentation to find out where that file is) depends 
> on connection tracking. My crystal ball tells me it's a 
> > I'm running FC3, kernel version 2.6.10-1.766 with iptables version 
> > 1.2.11.
> As was suggested already, use the raw table NOTRACK target to 
> bypass connection tracking for the traffic you specify.
> > Is there a FAQ or information documented on how to do this (that's 
> > I've missed and will be wholly embarrassed when you point it out)?
> > Does anyone have any experience doing this they could share?
> Good heavens no! Connection tracking is the jewel in 
> netfilter's crown. 
> Why would I want to disable it?
> -- 
>     mail to this address is discarded unless "/dev/rob0"
>     or "not-spam" is in Subject: header

More information about the netfilter mailing list