From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: Problem accessing https://my.procurve.com/profile/index.aspx (ACK is over the upper bound) Date: Mon, 02 Jul 2007 16:46:24 +0200 Message-ID: <46890FC0.9050903@trash.net> References: <4688FC41.5070403@trash.net> <46890846.90907@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: netfilter-devel@lists.netfilter.org To: Jozsef Kadlecsik Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-devel-bounces@lists.netfilter.org Errors-To: netfilter-devel-bounces@lists.netfilter.org List-Id: netfilter-devel.vger.kernel.org Jozsef Kadlecsik wrote: > On Mon, 2 Jul 2007, Patrick McHardy wrote: > >>>> We should really document that with window tracking and NAT you >>>> must drop INVALID packets to avoid them getting delivered locally >>>> and causing a RST. >>> >>> >>> Couldn't we do it in NAT itself? I.e drop the packet by NAT if >>> ip_conntrack_tcp_be_liberal is unset and the packet is INVALID. >> >> >> I'm a bit sceptical about NAT core caring about TCP conntrack >> specific sysctls, I'd prefer an unconditional drop. > > > NAT works on top of conntrack so peeking the flags were not completely > perverse ;-). If NAT drops INVALID packets undconditionally, that'd > disable the sysctl flag completely and we had to say "this sysctl > setting cannot be used if the NAT module is loaded in". Would it really? The sysctls flag makes *more* packets be regarded as valid, so I'm not I'm following .. > >>> It'd be backward-incompatible as it'd change the current behaviour but >>> were more safer (saner) than the present approach. >> >> >> Yes, for this case it definitely makes sense. I'm just wondering >> whether we'll break anything. Tools like nmap come to mind .. > > > Dropping packets is a good thing. :-) Incoming yes, outgoing .. who knows :)