From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 05:29:36 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BED7BC3B; Wed, 4 Feb 2015 05:29:36 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8E634A97; Wed, 4 Feb 2015 05:29:36 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t145TW3e041754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:29:34 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1AE36.8090504@freebsd.org> Date: Wed, 04 Feb 2015 13:29:26 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option (version 2) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> In-Reply-To: <54D0FD9B.5000108@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:29:36 -0000 On 2/4/15 12:55 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 03.02.2015 19:13, Lev Serebryakov wrote: > >> Ok, "allow-state"/"deny-state" was very limited idea. Here is more >> universal mechanism: new "keep-state-only" (aliased as >> "record-only") option, which works exactly as "keep-state" BUT >> cancel match of rule after state creation. It allows to write >> stateful + nat firewall as easy as: > To work as expected, "keep-state-only" should not imply "check-state" > in opposite to "keep-state". agreed.. I hate the implied check-state.. man page must be very explicit about this..