Re: IPF 4.1.20

	Hello.  Is switching to pf, as opposed to ipf, an option? 
Seems like
you could do that witout upgrading, just by loading pf as a
kernel module
and then disabling ipf, or rather, probably in the reverse
order.  I've
used both, though pf more, and found pf to be much more
stable and
predictable.  I've got it running in several production
environments, and
it "just works", which is what I think you want. 
Granted, I'm not running a
bunch of NFS through it, but it has held up better in
situations where I've
had problems with ipf.

Just a thought.
-Brian
On May 5,  7:39pm, Hauke Fath wrote:
} Subject: Re: IPF 4.1.20
} [ipfilter update for netbsd-4]
} 
} At 16:16 Uhr +0000 5.5.2007, Christos Zoulas wrote:
} >Have you tested -current and it works?
} 
} No, I haven't. There have been discussions on the ipfilter
list about
} problems with stateful connections, and I had a vague hope
that newer
} versions of ipfilter would fix that... probably
over-optimistic of me.
} 
} This is about a production router serving ~100 people, and
I already felt
} adventurous with upgrading it to netbsd-4, hoping that
would fix the NFS
} issues with linux 2.6.x systems. It didn't, but added new
ones. I'd have to
} set up a test network with a -current machine, and try to
reproduce the
} problems... which I should have done before, probably.
Given my current
} schedule work, that's unlikely to happen this month, though.
} 
} 	hauke
} 
} --
} "It's never straight up and down"     (DEVO)
} 
} 
>-- End of excerpt from Hauke Fath

[problems with ipf and stateful nfs traffic]

At 8:32 Uhr -0700 7.5.2007, Brian Buhrow wrote:
>Is switching to pf, as opposed to ipf, an option?

I thought about that a while back. As it is, I came across
three major
obstacles, two of technical nature, and one of... well,
social nature.

The technical issues are that (a) pf keeps state
per-interface (or so I
understand), whereas ipf state is machine-global. The
machine in question
routes to eight subnets, and pf would considerably increase
the number of
stateful rules per interface. You could probably work around
that by
extensive use of macros, but I find that inflates the
namespace and rather
obscures the rule base. And (b), my current ruleset relies
heavily on
(per-interface) groups, for structuring the ruleset more
than performance,
and pf does not support groups.

The social issue is that I seem to be emotionally
incompatible with what
appears to be normal tone towards people asking questions on
openbsd lists.

The more I think of it, the more sense it makes to set up a
test
environment, both to reproduce the problems I see outside a
production
environment, and to try out various software.

	hauke

--
"It's never straight up and down"     (DEVO)