If you are sure conntrack is disabled (which often not if you just don't use any conntrack rules) I don't have any other ideas because I've never tested netfilter in "extreme" environments. Depending on your setup it might be possible to install two redundant machines but I've never tried such a configuration.
Willi
Shaun Hedges wrote:
Hi Willi,
I used conntrack originally but the state table filled up very fast and I began having connection errors, so i'm simply using forward rules now.
Do you have anymore ideas or does anyone else? I'm seeing some different behaviour now without changing anything..
But still, can netfilter do the job?
Thx
-----Original Message----- From: netfilter-admin@xxxxxxxxxxxxxxxxxxx [mailto:netfilter-admin@xxxxxxxxxxxxxxxxxxx]On Behalf Of Willi Mann Sent: Wednesday, September 03, 2003 6:20 AM To: netfilter@xxxxxxxxxxxxxxxxxxx; sh@xxxxxxxxxxxxxx Subject: Re: Netfilter max simultaenous connections limit>?
Hello,
We have high speed applications that open up hundreads of threads per computer very fast then close then open again. At one time, we can have about 15000 tcp connections going through the firewall at once. We've recently been adding more application servers but we're noticing that the bandwidth usage isn't going up intune with the number of computers, it's actually staying around the same. We know this shouldn't be the case so
am
wondering if 15000+ connections is too much for a RH Linux+netfilter configuration using no stateful inspection just basic FORWARD'ing rules to block all traffic from those machines except one port coming in. Our firewall rules: *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :RH-Lokkit-0-50-INPUT - [0:0] -A INPUT -j RH-Lokkit-0-50-INPUT -A RH-Lokkit-0-50-INPUT -i eth0 -j ACCEPT -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 65456 --syn -j ACCEPT -A RH-Lokkit-0-50-INPUT -i lo -j ACCEPT -A FORWARD -d 192.168.168.0/27 -p udp -m udp --sport 53 -j ACCEPT -A FORWARD -d 192.168.168.0/27 -p udp -m udp --dport 53 -j ACCEPT -A FORWARD -d 192.168.168.0/27 -p tcp -m tcp --syn -j DROP -A FORWARD -d 192.168.168.0/27 -p udp -j DROP -A RH-Lokkit-0-50-INPUT -p udp -m udp -s 0/0 --sport 53 -d 0/0 -j ACCEPT -A RH-Lokkit-0-50-INPUT -p udp -m udp -s 0/0 --dport 53 -d 0/0 -j ACCEPT -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --dport 80 --syn -j ACCEPT -A RH-Lokkit-0-50-INPUT -p tcp -m tcp --syn -j REJECT -A RH-Lokkit-0-50-INPUT -p udp -m udp -j REJECT
COMMIT
WE basically just allow nothing in to the subnet but everything out..
Our router is a P1.7ghz Celeron w/ 512mb ram and IDE disks and 2 3com NIC nic cards.. Is this insufficient? Our b/w usage is a mere 2.5mbits, but
we
have about 8mbits available, and when it goes up, we seem to add more incoming bandwidth as outgoing, it looks as though the errors or timeouts are increasing.
Any ideas? Do I have to increase a limit in anyway?
Hi! Conntrack always notes (in my expierence) the state of connections if loaded.
1) Check if ip_conntrack -module is loaded. (lsmod). If it is not and it is not directly compiled into the kernel, my ideas won't help you.
2) Check /proc/sys/net/ipv4/ip_conntrack_max
3) Check /proc/net/ip_conntrack at high load. (wc -l ip_conntrack) If the value is close to 2) then you can: *Set /proc/sys/net/ipv4/ip_conntrack_max to a higher value (which seems to be the worst idea because connection-tracking without needing it just eats up ressources.) *Try to remove ip_conntrack with rmmod. *Check if the notrack module is available in your kernel. You would need an addition rule. *Remove the ip_conntrack.o -module from lib/modules/2.4.21/kernel/net/ipv4/netfilter (Don't know if that makes problems) *Compile the (RedHat-)kernel without connection-tracking. I think that this would be the best choice for your setup because it is the cleanest way. *And as always in Linux, there might be other solutions I havn't considered.
Hope this helps and it's not that netfilter just hasn't got enough power for your needs.
Willi Mann
