Date: Mon, 10 Oct 2011 20:34:33 +0700 From: Victor Sudakov <vas@mpeks.tomsk.su> To: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: need help with pf configuration Message-ID: <20111010133433.GA31810@admin.sibptus.tomsk.ru> In-Reply-To: <4E9184D4.50303@infracaninophile.co.uk> References: <CAEZdUGikPzsN=q-m_szHJCGxGT81UGA7Lbd7remTDdiqM5p3og@mail.gmail.com> <20111008235238.GB3136@hs1.VERBENA> <CAEZdUGiV_aXM67S4Yfw-i5tPZcwCWOiKPSFCPBOLkCfWjMmjeQ@mail.gmail.com> <20111009015141.GA60380@hs1.VERBENA> <20111009051554.GA91440@admin.sibptus.tomsk.ru> <20111009083855.0e9879f6@davenulle.org> <20111009073910.GB92531@admin.sibptus.tomsk.ru> <20111009113106.3848a1cb@davenulle.org> <4E9184D4.50303@infracaninophile.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Seaman wrote: > > > >>>> > > > I need no details, just a general hint how to setup such security > >>>> > > > levels, preferably independent of actual IP addressses behind the > >>>> > > > interfaces (a :network macro is not always sufficient). > >>> > > > >>> > > You may use urpf-failed instead :network > >>> > > urpf-failed: Any source address that fails a unicast reverse path > >>> > > forwarding (URPF) check, i.e. packets coming in on an interface > >>> > > other than that which holds the route back to the packet's source > >>> > > address. > >> > > >> > Excuse me, I do not see how this is relevant to my question (allowing > >> > traffic to be initiated from a more secure interface to a less secure > >> > interface and not vice versa). > > Sorry, you can't do this with pf, ipf or ipfw (the 3 firewalls in > > FreeBSD). There is no concept of security level at all, you must specify > > on each interface the traffic allowed (in input and output). > > > > My reply was about the use of the interface:network addresses. > > pf has the concept of packet tagging. So you can write a small rule to > tag traffic crossing eg. your set of internal interfaces and then write > one ruleset to filter all that traffic identified by tag. Thank you again. Tags rule! The following excerpt illustrates the concept I have tested in my lab: pass in on $dmz from any to any tag FROMDMZ pass in on $inside from any to any block out on $inside tagged FROMDMZ The second rule is required to create state for the return traffic to flow from $dmz to $inside. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111010133433.GA31810>