From owner-freebsd-ipfw@FreeBSD.ORG Sat Nov 15 05:51:58 2008 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC1B1065670; Sat, 15 Nov 2008 05:51:58 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [220.233.188.227]) by mx1.freebsd.org (Postfix) with ESMTP id 78A298FC12; Sat, 15 Nov 2008 05:51:57 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id mAF5pp4a005289; Sat, 15 Nov 2008 16:51:52 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 15 Nov 2008 16:51:51 +1100 (EST) From: Ian Smith To: Julian Elischer In-Reply-To: <491D406F.5030806@elischer.org> Message-ID: <20081115024024.O70117@sola.nimnet.asn.au> References: <491CD94F.3020207@elischer.org> <20081114133913.K70117@sola.nimnet.asn.au> <491D375D.1070809@elischer.org> <491D406F.5030806@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Net , ipfw@freebsd.org Subject: Re: rc.firewall quick change X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2008 05:51:58 -0000 On Fri, 14 Nov 2008, Julian Elischer wrote: > Julian Elischer wrote: > > Ian Smith wrote: > > > On Thu, 13 Nov 2008, Julian Elischer wrote: > > > > At home I use the following change. > > > > > > basically, instead of doing 8 rules before and after the nat, > > > > use a table and to 1 rule on each side. > > > > > > any objections? > > > > > > Only that if people are already using tables for anything, chances are > > > they've already used table 1 (well, it's the first one I used :) How > > > about using table 127 for this as a rather less likely prior choice? > > > > yes I thought of that.. > > in fact it should be ${BLOCKTABLE} and let the user define what he wants. > > (defaulting to 99 or something). I prefer binary, but whatever :) > > Remember though that a user wouldn't be using 'simple' if he's using his > > own tables etc. This is an important point. Please allow me a little pent-up critique: Originally, eg for me over 10 years ago, till recently, the only way to use the 'client' or 'simple' rulesets was to hack rc.firewall, which I did relentlessly, like many people I'm sure .. that is, we treated it more as a starter example, not something that could be used as is. More recent updates have introduced rc vars that concievably make these rulesets usable out of the box, in as much as you could tell a newbie to FreeBSD firewalls and ipfw in particular, "setup these vars for your network, select the 'client' or 'simple' ruleset as appropriate, and you have a fair chance of having a fairly functional and reasonably secure firewall to get yourself online and going until you learn a bit more". Combined with the deprecatory and in many instances just plain erroneous info in the only section of the Handbook that I've felt to try rewriting more or less from scratch - ie the ipfw part of the firewall chapter 31, which suggests some quite (to me) bizarre example rulesets after having dissed using the rc.firewall rulesets out of hand - we're not doing much good at advocating new users trying ipfw, which I think does it some injustice. Not intending here to deprecate pf or ipf in any way. Anyhow, this leaves us with two good reasons that 'client' and 'simple' sections ought to work effectively: secondly as an example illustrating good techniques - and I think your use of a table that the user can add entries to out of band for such as blackholing hosts/nets without having to reconfigure or restart the firewall IS good technique - but firstly as a basically functional and secure minimal firewall in and of itself. It's for both those reasons (and fixing an apparent oversight) that I've offered my unreviewed patch (which I'll do properly by PR if anyone says it's worth pursuing), after years of not being able to fathom supposedly usable firewall configuration for a client or small net, with or without NAT, that has never passed =ANY= ICMP traffic, not even to or from the hosts in one's own net! Am I missing something, thinking that matters, and that functioning path MTU discovery matters? > so here's a slightly improved diff: This may be a bit nitpicky, but how about keeping the firewall_simple_* varset naming consistent, maybe firewall_simple_blocktable or something? The 'workstation' vars have kinda busted that idea anyway, but still .. Also maybe rephrase mentioning the draft-manning-blah after the divert? HTH, Ian