From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 0/3] netfilter : 3 patches to boost ip_tables performance Date: Fri, 07 Oct 2005 19:50:57 +0200 Message-ID: <4346B581.9060603@trash.net> References: <432EF0C5.5090908@cosmosbay.com> <20051006175956.GI6642@verdi.suse.de> <4346AB94.4050006@trash.net> <200510071921.40343.ak@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Harald Welte , netdev@vger.kernel.org, netfilter-devel@lists.netfilter.org, linux-kernel@vger.kernel.org, Henrik Nordstrom Return-path: To: Andi Kleen In-Reply-To: <200510071921.40343.ak@suse.de> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Andi Kleen wrote: > On Friday 07 October 2005 19:08, Patrick McHardy wrote: > > I don't know about other distributions but SUSE at some point > found that some web benchmarks dramatically improved in the default > configuration when local conntrack was off. It was off then since ever. Interesting .. >>When an ICMP error is send by the firewall itself, the inner >>packet needs to be restored to its original state. That means >>both DNAT and SNAT which might have been applied need to be >>reversed. DNAT is reversed at places where we usually do >>SNAT (POST_ROUTING), SNAT is reversed where usually DNAT is >>done (PRE_ROUTING/LOCAL_OUT). Since locally generated packets >>never go through PRE_ROUTING, it is done in LOCAL_OUT, which >>required enabling NAT in LOCAL_OUT unconditionally. It might >>be possible to move this to some different hook, I didn't >>investigate it. > > This sounds wrong anyways. You shouldn't be touching conntrack state for ICMPs > generated by routers because they can be temporary errors (e.g. during a > routing flap when the route moves). Only safe way to handle this is to wait > for the timeout which doesn't need local handling. And the firewall cannot be > an endhost here. You misunderstood me. Its not about conntrack state, its about the inner packet contained in the ICMP message. If it was NATed by the box itself before the ICMP message is generated, it needs to be restored to its original state, otherwise the receipient will ignore it.