Skip site navigation (1)Skip section navigation (2)
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>