Skip to contentSkip to conversation

HELP: Conntrack table filling up !!!

DISCUSSION Mircea Ciocan 3 participants 5 messages Dec 23, 2002 – Jan 2, 2003 netfilter

lore
Share & tools
lore
#0 lore raw

Hi everybody,

I have this problem with connexion tracking table filling to the max
and then it remains in a state "near the edge" that will allow only a small number of new conexions and will cause a large packet loss, even "sendto: operation not permited" sometimes when I ping the neighboor routers and so on.
Everything got cleared up if I delete the ip tables rules that deal
with contrack and remove and reinsert ip_conntrack module.
Now if there is some method of avoiding this ( I only see a discution
from 2001 that was not conclusive) or if there is is an method to time-out faster those conexions in conntrack table or even a method of globaly quick-flush that table ( could be a even an experimental patch, I'm willing to try it and report) I'd very muck like to hear about it.
Anyhow, thank you for your good work and have a happy new year.

Regards,

Mircea Ciocan

P.S. kernel is 2.4.18 and machine have enough ram ( 512 MB) and processing power ( P-III 800MHZ), traffic is something like 50 Mb/s top ans 25-30 medium.

#1 lore raw

There are ways in which pings (ICMP packets) can fill up conntrack tables quickly. Are you running into problems with ICMP traffic only or with any traffic ? e.g. look at /proc/net/ip_conntrack . Is it filled up with ICMP traffic connections only ? If so, you might want to protect your linux box from malformed ICMP packets, by DROPping all such packets in the "filter" table.

Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
771 Vaqueros Avenue
Sunnyvale CA 94085
USA
[email protected]
http://www.zultys.com/

Quoted 42 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Mircea Ciocan
Sent: Monday, December 23, 2002 11:00 AM
To: [email protected]
Cc: [email protected]
Subject: HELP: Conntrack table filling up !!!

Hi everybody,

I have this problem with connexion tracking table
filling to the max
and then it remains in a state "near the edge" that will allow only a small number of new conexions and will cause a large packet loss, even
"sendto: operation not permited" sometimes when I ping the neighboor routers and so on.
Everything got cleared up if I delete the ip tables
rules that deal
with contrack and remove and reinsert ip_conntrack module.
Now if there is some method of avoiding this ( I only
see a discution
from 2001 that was not conclusive) or if there is is an method to time-out faster those conexions in conntrack table or even a method of
globaly quick-flush that table ( could be a even an experimental patch,
I'm willing to try it and report) I'd very muck like to hear about it.
Anyhow, thank you for your good work and have a happy new year.

Regards,

Mircea Ciocan

P.S. kernel is 2.4.18 and machine have enough ram ( 512 MB) and processing power ( P-III 800MHZ), traffic is something like 50 Mb/s top
ans 25-30 medium.

#2 lore raw
Quoted 7 lines · Ranjeet Shetye

There are ways in which pings (ICMP packets) can fill up conntrack tables quickly. Are you running into problems with ICMP traffic only or with any traffic ? e.g. look at /proc/net/ip_conntrack . Is it filled up with ICMP traffic connections only ? If so, you might want to protect your linux box from malformed ICMP packets, by DROPping all such packets in the "filter" table.

Don't arbitrarily drop all ICMP, bad idea, breaks a few things.

Couldn't the 'full ip conntrack table' problem be solved by echo'ing a
bigger number into /proc/sys/net/ipv4/ip_conntrack_max ?

	root@jimblewix:/proc/sys/net/ipv4;
	23:48:19 0$ echo 32768 > ip_conntrack_max 

certainly changes it here.

-Ath

Signature · 4 lines
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME
#3 lore raw

Oh no, definitely, I was only talking of dropping the malformed packets. Unfortunately, how do you identify/match malformed ICMP packets in iptables ?? Don't know that one.

Actually, the ICMP problem that I have seen does not go away with a larger ip_conntrack_max. The extra table space just gets filled up. Agreed, that the ICMP packets I used to flood the iptables conntrack mechanism did not strictly comply with ICMP RFC standards, but then which cracker cares about standards ? :( That's why I asked, are you seeing malformed ICMP packets ?

Ranjeet Shetye
Senior Software Engineer
Zultys Technologies
771 Vaqueros Avenue
Sunnyvale CA 94085
USA
[email protected]
http://www.zultys.com/

Quoted 38 lines

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Athan
Sent: Tuesday, December 31, 2002 3:50 PM
To: [email protected]
Subject: Re: HELP: Conntrack table filling up !!!

Quoted 3 lines · Ranjeet Shetye

There are ways in which pings (ICMP packets) can fill up conntrack tables quickly. Are you running into problems with ICMP

traffic only

Quoted 2 lines

or with any traffic ? e.g. look at /proc/net/ip_conntrack . Is it filled up with ICMP traffic connections only ? If so, you

might want

Quoted 1 line

to protect your linux box from malformed ICMP packets, by

DROPping all

Quoted 1 line

such packets in the "filter" table.

Don't arbitrarily drop all ICMP, bad idea, breaks a few things.

Couldn't the 'full ip conntrack table' problem be solved by
echo'ing a bigger number into /proc/sys/net/ipv4/ip_conntrack_max ?

	root@jimblewix:/proc/sys/net/ipv4;
	23:48:19 0$ echo 32768 > ip_conntrack_max 

certainly changes it here.

-Ath

Signature · 5 lines
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." 
Paula Cole - ME
#4 lore raw
Quoted 6 lines · Ranjeet Shetye

Actually, the ICMP problem that I have seen does not go away with a larger ip_conntrack_max. The extra table space just gets filled up. Agreed, that the ICMP packets I used to flood the iptables conntrack mechanism did not strictly comply with ICMP RFC standards, but then which cracker cares about standards ? :( That's why I asked, are you seeing malformed ICMP packets ?

Fair enough. Check out if the unclean match module catches these bad
ICMP packets then:

	iptables -A INPUT -i ${PUBINT} --match unclean -j LOG --log-level info --log-prefix "fwr-unclean "

-Ath

Signature · 4 lines
- Athanasius = Athanasius(at)miggy.org / http://www.miggy.org/
                  Finger athan(at)fysh.org for PGP key
	   "And it's me who is my enemy. Me who beats me up.
Me who makes the monsters. Me who strips my confidence." Paula Cole - ME