From owner-freebsd-net@FreeBSD.ORG Sat Apr 5 17:53:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7A988106564A for ; Sat, 5 Apr 2008 17:53:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 493828FC17 for ; Sat, 5 Apr 2008 17:53:25 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Sat, 05 Apr 2008 13:41:01 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 181CE2D6011; Sat, 5 Apr 2008 10:53:22 -0700 (PDT) Message-ID: <47F7BC95.7090907@elischer.org> Date: Sat, 05 Apr 2008 10:53:25 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Ian Smith References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Ivan Voras Subject: Re: Trouble with IPFW or TCP? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2008 17:53:25 -0000 Ian Smith wrote: > > I don't see why you think it's broken? Apart from obvious efficiency of > having a check-state rule earlier, to get on with matching this packet > against existing dynamic rules without wading through intervening rules, > state is still only checked once; like it says, the O_PROBE_STATE opcode > only causes a state check at the first check-state, keep-state or limit > rule (encountered); any others found then become a short-path NOP. > > Personally I like to do traffic accounting before any packet is whisked > off to be dealt with (and accounted by) any keep-state rules, though as > your example shows that can be done afterwards, if not piped or such. > > But I can't see why you ever wouldn't want to check the existing state > of any src-addr/src-port <-> dst-addr/dst-port packet before attempting > to add a new dynamic rule for that same session? My firewall rules a re very complex and I could want to change the action stored with a particular session.. trivial example: Assuming that keep-state did NOT do a check state: 10 check-state 100 skipto 1000 tcp from any to any in $inside keep-state [...] 1000 skipto 2000 tcp from any to any iplen 1480-9200 keep-state [...] 2000 count log ip from any to any [....] now I change the action for jumbo packets for accounting purposes to go straight to 2000 with implicit check state.. 1/ I have no way of changing what to do as the keep-state on 100 will never bee done 2/ I have no idea what happens when you effectlvely do a "1000 skipto 1000".