rc.firewall quick change

[Ian Smith]

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