filtering bridges [was: PF error message looping on screen]

[Ermal Luçi]

> On 06/16/07 21:29, Adam McDougall wrote:
> > On Sat, Jun 16, 2007 at 05:20:39PM +0200, Volker wrote:
> ...
>
> >   If that doesn't help, I recommend rewriting your rules a bit and use
> >   'set state-policy if-bound' (which I'm using most as I find it better
> >   to administer). Unfortunately I don't have experience with
> >   state-policy if-bound in a bridged environment (just a little warning).
> >
> > I was thinking the same thing regarding if-bound.  I use if-bound in production
> > on a pf bridge and found it avoids lots of loose state match and other state
> > confusion.  Also, I have found using pf loud debugging tends to deadlock the
> > console after not too long if I have more than one cpu enabled, so I avoid
> > using it in production.  After much testing, I feel comfortable without it,
> > however interesting it is.
>
> Adam,
>
> Thanks for your hint. I wasn't quite sure if if-bound works on bridges
> as I don't have much bridge experiences.
>
> On a bridge, does it make sense to filter on bridge0 or is it
> generally better to filter on it's member interfaces?
>
> Using a quick google search, I found some problems when filtering on
> the bridge interface in the past but if I would be in need of setting
> up a bridge, it would be the first thing for me to filter on the
> bridge interface and not on the member interfaces. What's the big
> reason for either?

The reason is that you will see the same packets twice with different
directions on the same interface(bridge#).
Since it passes the bridge twice, one entering it with direction 'in',
and then when living it with direction 'out'. So it gets really tricky
to create rulesets in such conditions unless you know what you're
doing.

Hence, the solution filtering on members which will see only once a
packet and aviod complexity.

>
> Thanks
>
> Volker
>
>

Ermali