Date: Sat, 24 Mar 2012 22:08:29 -0700 From: Julian Elischer <julian@freebsd.org> To: Da Rock <freebsd-ipfw@herveybayaustralia.com.au> Cc: freebsd-ipfw@freebsd.org Subject: Re: newbie IPFW user - when handbook examples dont work... Message-ID: <4F6EA84D.1010604@freebsd.org> In-Reply-To: <4F6E7E39.8080805@herveybayaustralia.com.au> References: <4F5A161C.8060407@herveybayaustralia.com.au> <8823954.VFuFedYPUb@magi> <4F644CF4.2010004@herveybayaustralia.com.au> <4F64BC7A.8080607@freebsd.org> <4F6D1D00.1080607@herveybayaustralia.com.au> <20120325013410.H2060@sola.nimnet.asn.au> <4F6E7E39.8080805@herveybayaustralia.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/24/12 7:08 PM, Da Rock wrote: > On 03/25/12 02:56, Ian Smith wrote: >> On Sat, 24 Mar 2012, Da Rock wrote: >> > On 03/18/12 02:31, Julian Elischer wrote: >> > > On 3/17/12 1:36 AM, Da Rock wrote: >> > > > On 03/14/12 17:09, Rémy Sanchez wrote: >> > [everything deleted].. ok I'm going to write a little blurb here, as someone who has, 1/ contributed to ipfw 2/ written python code to manipulate ipfw real-time (for code running in cisco appliances.. guess which ones) 3/ used it for many weird things at many times. here are my rules for using ipfw.. 1/ always use a script to make your firewalls.. start by siabling everything end by re-enabing comment extensively 2/ as soon as you start, split your flows to different rule ranges. even if that means duplicating rules... Once you have a set of rules for "incoming rules on re0" you never have to spend cpu cycles testing "in recv re0" on any further rules. It also means you don't have to think of every run of rules from the perspective of several different flows. yes you may have 7 different sets of rules if you have 3 interfaces and lo0, but you won't go insane. Inside rulesets can just be "allow ip from any to any" if you trust your inside interfaces. 3/ get really familiar with all the things you can do with tables. e.g. skipto tablearg/ 4/ use skipto creatively but remember you can oly skip forwards. 5/ remember that keep-state rules, when matched will duplicate whatever the original did so .... skipto 1000 ip from a to b keep-state will skip to 1000 whenever the state matches. this can lead to some really creative rulesets. 6/ when using NAT remember that rules before and after NAT are looking at different packets and that rules before nat are in local addresses going out but external addresses coming in, and teh opposite for after NAT. I always try catch incoming sessions that are actuallydestimed for the local machien before NAT so that my incoming sessions and local services still work if NAT fails. I have not yet used the new 'subroutine' functionality in current but am looking forward to playing with it. Julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F6EA84D.1010604>