From owner-freebsd-ipfw@FreeBSD.ORG Sun Sep 14 12:47:28 2014 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E485B0A; Sun, 14 Sep 2014 12:47:28 +0000 (UTC) Received: from smtp.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3861227; Sun, 14 Sep 2014 12:47:27 +0000 (UTC) Received: from rack1.digiware.nl (unknown [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id E80B91534EC; Sun, 14 Sep 2014 14:47:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlLW4Ph4l5qn; Sun, 14 Sep 2014 14:47:05 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 852E1153448; Sun, 14 Sep 2014 14:47:05 +0200 (CEST) Message-ID: <54158E49.7090102@digiware.nl> Date: Sun, 14 Sep 2014 14:47:05 +0200 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: IPFW rule sets and automatic rule numbering References: <541469D4.6070107@gmail.com> <54156FBB.1030907@digiware.nl> <20140914204055.K61666@sola.nimnet.asn.au> In-Reply-To: <20140914204055.K61666@sola.nimnet.asn.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Alexander V. Chernikov" , Freddie Cash , bycn82 , freebsd-ipfw@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: Sun, 14 Sep 2014 12:47:28 -0000 On 14-9-2014 13:44, Ian Smith wrote: > On Sun, 14 Sep 2014 12:36:43 +0200, Willem Jan Withagen wrote: > > On 13-9-2014 21:51, Freddie Cash wrote: > > > You can replicate it using 3 rules, loaded into two sets: > > > > > > ipfw set disable 1 > > > ipfw add allow ip from any to any > > > ipfw add 65524 allow ip from any to any > > > ipfw add allow ip from any to any > > > ipfw set swap 1 0 > > > > > > Run that two or 3 times. Every rule will be numbered 65534 after the 2nd or > > > 3rd run. > > > > > > > > I expected it to be numbered 10, 65524, 65534 after every run. > > > > > > However, after reading the man page a few more times and thinking about it > > > a little more, it makes sense that the numbering is global across all sets, > > > as you can have multiple sets enabled simultaneously. > > > > > > It just doesn't mesh with my desire to use auto numbering. I'm in the midst > > > of manually numbering all my rules now. :) > > > This is easily circumvented by making shure that the first rule is > > > > ipfw add 10 ..... > > like: > > ipfw add count ip4 from any to any via vlan126 > > (vlan126 is my outside connection) > > And then you are home free. > > > > I actually use this to also separate diffent types of block by injecting: > > ipfw add count ip from any to any > > > > like: > > 03000 713812041 425643462848 count ip from any to any > > 03010 0 0 deny ip6 from fc00::/7 to any via vlan126 > > > > And the 3000 block contains all antispoofing and likes. > > I'd almost replied along the same lines - also tending to number first > rules in a block and then add unnumbered rules until other sections - > before realising that once Freddie had added his rule 65524, maybe in > another set, it's game over; every unnumbered rule added after that is > going to be >= 65524 and <= 65534. > > And even as you have it above, if you rerun your script again without > flushing the entire ruleset, apart from specifically numbered rule/s, > everything will get readded after the highest rule previously used. > > Alexander said: > > I think we can consider implementing sysctl which permits per-set > > auto-numbering. > > Perhaps rather than a separate high water mark per set that would be > reset on set N flush - which I think is what Alexander means? - if one > could set something like maybe 'net.inet.ip.fw.autoinc_last' which would > default, as now, to the highest rule added so far, but could be reset to > something else before adding more auto_inc rules? Might get tricky, and > of course it has to not break older rule scripts - some VERY old :) Could very well be. I was for the same reason going to implement Freddy's strategy and swap sets... So could be that I'd run into the same problem in near future. It is hard to imagine that people would depend on the fact that the last rule used would survive a set swap, and actually build on it. Being able to actual set the last number used, aka the next number to be assigned, would be equivalent to my trick using 'ipfw add count....' to preset a certain startingpoint. It could even be made into either a flag on ipfw like -k keep the last index for future increment or an ipfw instruction ipfw setautoincr And that would not interfere with old scripts. tinkering it through sysctl would be possible too, but I'd prefer things like this integrated in the command-interface. --WjW