From owner-freebsd-pf@freebsd.org Wed Sep 28 13:36:36 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 650EAC008B3 for ; Wed, 28 Sep 2016 13:36:36 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33D6F1A09 for ; Wed, 28 Sep 2016 13:36:36 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [192.168.228.1] (vega.codepro.be [IPv6:2a01:4f8:162:1127::3]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id D591036CDF; Wed, 28 Sep 2016 15:36:33 +0200 (CEST) From: "Kristof Provost" To: "Franco Fichtner" Cc: freebsd-pf@freebsd.org Subject: Re: pf fastroute tag removal reviewers needed Date: Wed, 28 Sep 2016 15:36:34 +0200 Message-ID: In-Reply-To: <022E4530-A6DF-452B-8978-43A9B10DA726@opnsense.org> References: <022E4530-A6DF-452B-8978-43A9B10DA726@opnsense.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6056) 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: Wed, 28 Sep 2016 13:36:36 -0000 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. Agreed, but there’s another culprit: the v6 fragment handling code. It needs to call ip6_output()/ip6_forward() because it generates multiple output packets. Dealing with that has been on my todo list for a while now, but I’ve not even found the time to make a start at it. Regards, Kristof