Date: Thu, 21 May 2009 10:20:40 -0700 From: Freddie Cash <fjwcash@gmail.com> To: freebsd-ipfw@freebsd.org Subject: Re: Does ipfw support interface groups? Message-ID: <b269bc570905211020m14404e0aq230038a5d8d5f967@mail.gmail.com> In-Reply-To: <4A158432.5050303@ibctech.ca> References: <9a542da30905210720y50fafe59ld3459c9e76ef5824@mail.gmail.com> <20090521150113.GA47160@onelab2.iet.unipi.it> <b269bc570905210849s202084d2h15e991683d1b112b@mail.gmail.com> <4A158432.5050303@ibctech.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 21, 2009 at 9:41 AM, Steve Bertrand <steve@ibctech.ca> wrote:
> Freddie Cash wrote:
>> On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo <rizzo@iet.unipi.it> wrote:
>>> On Thu, May 21, 2009 at 04:20:48PM +0200, Ermal Lu?i wrote:
>>>> can ipfw use somehow interface groups as pf(4) can?
>>>> From a quick glance at documentation and not so through look at code
>>>> it does not but i am sending this just if i missed something during my
>>>> search!
>>> something like
>>> =C3=82 =C2=A0=C3=82 =C2=A0=C3=82 =C2=A0=C3=82 ... { recv ed0 or recv xl=
1 or recv ath4 or recv vlan0 } ...
>>> is perhaps not so nice but does the job.
>>
>> Seriously??!!
>>
>> Luigi, you just made my day. =C2=A0:) =C2=A0Writing duplicate sets of ru=
les for
>> multi-homed firewalls where the only thing that's different is the
>> incoming interface has been a pain ...
>
> Aside from Luigi's piece of trickery, if you are accustomed to making
> frequent changes to live rulesets (and then promptly
> forgetting/neglecting to add them into your startup scripts), might I
> recommend something that has become very useful to me:
>
> I have /etc/ipfw.rules which contains the variable definitions and all
> table configurations as my primary startup script. At the bottom of that
> file, I have:
>
> . /etc/ipfw.include
>
> This instructs the sh script to pick up the data from the ipfw.include
> file, and process it as well.
We do something similar, with a global config file with all the common
variables, tables, queues, etc; and a master script with the rules for
the firewall itself and the master NAT setup, which then pulls in
separate scripts for each 1-to-1 NAT for servers at the sites. We
make very heavy use of shell variables, tables, and the like.
> Instead of implementing the rules live, and then adding them into the
> startup script manually, I simply (from time-to-time) run this
> (copy/paste into CLI):
>
> ipfw list | \
> perl -nle 's/table\((\d+)\)/\"table($1)"/g; print "\$cmd $_";' \
>> /etc/ipfw.include
> chown root:wheel /etc/ipfw.include && chmod 400 /etc/ipfw.include
>
> That then makes a copy of your current live ruleset into your
> /etc/ipfw.include file, which will be loaded upon next reboot.
We do something similar every now and again to keep a backup of the
live rules, just in case. But it's only used to compare against the
live rules at a later date. Due to the heavy use of variables and
formatting in our scripts, there's no way we'd consider using this
output as an input script. :) It's hard enough to read the output of
ipfw when it's running ... I wouldn't want to have to wade through
that to add/update rules saved to a file. :)
--=20
Freddie Cash
fjwcash@gmail.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b269bc570905211020m14404e0aq230038a5d8d5f967>