Hi current,

There is a growing concern over usability of netpfil with
several premature exits out of the framework that would
seem to try to provide consistent policy enforcement on
traffic, namely:

if_output: called by pf route-to type tags, in 12-CURRENT
also from ipfw nat64 -- if_output in the netpfil in hook
skips pending hooks in the IN direction and all of the OUT

ip(6)_output: several callers in both ipfw and pf -- skips
all pending netpfil hooks in the IN direction.

The problem is elevated by the fact that we can use
pf and ipfw together, in a number of use cases leading
up to as much as 75% of the netpfil hook chain skipped.

I'm not saying that these are bugs as that has likely been
the default behaviour for years, but it also looks like
this is quite fixable yielding several benefits:

o getting rid of duplicated ip_output code in netpfil
o straightening out packet policy application
o improving usefulness of joint ipfw + pf scenarios

This is a real concern for our OPNsense users, who e.g. run
captive portals based on ipfw, but can't run multi-WAN
setups with pf at the same time--two use cases which run
perfectly fine as stand-alone configurations.

I've opened a review to start removal of if_output from the
pf code with a conservative first batch, which would eventually
enable ipfw and pf redirect packets using the same PACKET_TAG_IPFORWARD
mechanism.  It was met with multiple opinions, but no agenda out
of the current situation:


Since the discussion went stale, I would like to pose three
questions to a wider audience:

Is there interest in keeping the netpfil framework consistent
for use with either ipfw or pf?

Is there interest in keeping the netpfil framework consistent
for use with ipfw and pf running at the same time?

Is there anyone willing to review and guide work towards
correcting these oddities?

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to