*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 :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :MYRULE-INPUT - [0:0] -A INPUT -j MYRULE-INPUT -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 MYRULE-INPUT -i lo -j ACCEPT -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 COMMIT -----Original Message----- From: netfilter-bounces@xxxxxxxxxxxxxxxxxxx [mailto:netfilter-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of /dev/rob0 Sent: 26 August 2005 14:17 To: netfilter@xxxxxxxxxxxxxxxxxxx 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 MASQUERADE rule. > 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
