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, good to know, someone else will re-check my writings! ;) A couple of days ago I was writing something totally stupid but nobody complained (conclusion: I will avoid posting to mailing lists when my uptime is -gt 24h). 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? Thanks Volker _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[EMAIL PROTECTED]"
