On Thu, May 21, 2009 at 9:41 AM, Steve Bertrand <st...@ibctech.ca> wrote:
> Freddie Cash wrote:
>> On Thu, May 21, 2009 at 8:01 AM, Luigi Rizzo <ri...@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
>>> Â Â Â Â ... { recv ed0 or recv xl1 or recv ath4 or recv vlan0 } ...
>>> is perhaps not so nice but does the job.
>>
>> Seriously??!!
>>
>> Luigi, you just made my day. :) Writing duplicate sets of rules 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. :)
--
Freddie Cash
fjwc...@gmail.com
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
