From owner-svn-src-all@FreeBSD.ORG Mon Apr 6 20:58:18 2015 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4561F6A; Mon, 6 Apr 2015 20:58:18 +0000 (UTC) Received: from mx0.thekeelecentre.com (mx0.thekeelecentre.com [88.98.64.52]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 825F036D; Mon, 6 Apr 2015 20:58:18 +0000 (UTC) Received: from filter.mx0.thekeelecentre.com (unknown [88.98.64.55]) by mx0.thekeelecentre.com (Postfix) with ESMTP id C529C22C1F; Mon, 6 Apr 2015 21:50:26 +0100 (BST) X-Virus-Scanned: amavisd-new at thekeelecentre.com Received: from mx0.thekeelecentre.com ([88.98.64.52]) by filter.mx0.thekeelecentre.com (filter.mx0.thekeelecentre.com [88.98.64.55]) (amavisd-new, port 10024) with ESMTP id C3APwxB2UESn; Mon, 6 Apr 2015 20:50:26 +0000 (UTC) Received: from [10.0.2.11] (nat-gw.hl.tector.org.uk [88.96.67.61]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mx0.thekeelecentre.com (Postfix) with ESMTPSA id 38B8022C15; Mon, 6 Apr 2015 21:50:26 +0100 (BST) Message-ID: <5522F192.7010205@thekeelecentre.com> Date: Mon, 06 Apr 2015 21:50:26 +0100 From: Richard Tector User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kristof Provost , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r281164 - head/sys/netpfil/pf References: <201504061905.t36J51EX005483@svn.freebsd.org> In-Reply-To: <201504061905.t36J51EX005483@svn.freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2015 20:58:18 -0000 On 06/04/2015 20:05, Kristof Provost wrote: > Author: kp > Date: Mon Apr 6 19:05:00 2015 > New Revision: 281164 > URL: https://svnweb.freebsd.org/changeset/base/281164 > > Log: > pf: Skip firewall for refragmented ip6 packets > > In cases where we scrub (fragment reassemble) on both input and output > we risk ending up in infinite loops when forwarding packets. > > Fragmented packets come in and get collected until we can defragment. At > that point the defragmented packet is handed back to the ip stack (at > the pfil point in ip6_input(). Normal processing continues. > > Eventually we figure out that the packet has to be forwarded and we end > up at the pfil hook in ip6_forward(). After doing the inspection on the > defragmented packet we see that the packet has been defragmented and > because we're forwarding we have to refragment it. > > In pf_refragment6() we split the packet up again and then ip6_forward() > the individual fragments. Those fragments hit the pfil hook on the way > out, so they're collected until we can reconstruct the full packet, at > which point we're right back where we left off and things continue until > we run out of stack. > > Break that loop by marking the fragments generated by pf_refragment6() > as M_SKIP_FIREWALL. There's no point in processing those packets in the > firewall anyway. We've already filtered on the full packet. > Kristof, Firstly, many thanks for working on this. I was just wondering how this affects the case where we might have if-bound rules? Really basic example: pass quick on $outside_if inet6 proto udp from any to $myhost block drop quick on $inside_if inet6 proto udp from any to $myhost port $secret_svc pass quick on $inside_if inet6 proto udp from any to $myhost If the fragments generated after processing occurs on the inbound interface are then marked to be skipped then will they therefore not be matched by the drop rule in the example above? Regards, Richard