From owner-freebsd-pf@freebsd.org Sat Oct 1 09:43:19 2016 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96C5DC04CF9 for ; Sat, 1 Oct 2016 09:43:19 +0000 (UTC) (envelope-from franco@opnsense.org) Received: from mail.opnsense.org (mail.opnsense.org [37.48.77.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 647AE1CE2; Sat, 1 Oct 2016 09:43:19 +0000 (UTC) (envelope-from franco@opnsense.org) Received: from localhost (localhost [127.0.0.1]) by mail.opnsense.org (Postfix) with ESMTP id 0532A1808FAB; Sat, 1 Oct 2016 11:46:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: pf fastroute tag removal reviewers needed From: Franco Fichtner In-Reply-To: Date: Sat, 1 Oct 2016 11:43:08 +0200 Cc: freebsd-pf@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <022E4530-A6DF-452B-8978-43A9B10DA726@opnsense.org> To: Kristof Provost X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Oct 2016 09:43:19 -0000 Hi Kristof, > On 28 Sep 2016, at 3:36 PM, Kristof Provost wrote: >=20 > On 28 Sep 2016, at 13:53, Franco Fichtner wrote: >> The main culprit of pfil not working correctly is pf's >> route-to and reply-to (and the tag formerly known as fastroute) >> as they would call if_output directly on the ifnet and consume >> their packets this way. That transmit code is also copied from >> if_output() and should likely not be called from within pf, >> especially when there is a pfil hook chain to go through. >=20 > Agreed, but there=E2=80=99s another culprit: the v6 fragment handling = code. It needs to > call ip6_output()/ip6_forward() because it generates multiple output = packets. >=20 > Dealing with that has been on my todo list for a while now, but I=E2=80=99= ve not even > found the time to make a start at it. Right, that also has some issues, but at least the pfil out hook is invoked with this. I see that ipfw also has some of those netinet code spots, which undermine the integrity of pfil. Would it make sense to take it to another mailing list to raise awareness the issue to at least not get any new code added that does this? Thanks, Franco=