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 direction. 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: https://reviews.freebsd.org/D8109 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? Thanks, Franco _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"