From owner-freebsd-pf@freebsd.org  Sun Nov  8 19:29:55 2015
Return-Path: <owner-freebsd-pf@freebsd.org>
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 447CDA29382
 for <freebsd-pf@mailman.ysv.freebsd.org>; Sun,  8 Nov 2015 19:29:55 +0000 (UTC)
 (envelope-from kp@vega.codepro.be)
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 0B06C108D
 for <freebsd-pf@freebsd.org>; Sun,  8 Nov 2015 19:29:54 +0000 (UTC)
 (envelope-from kp@vega.codepro.be)
Received: from vega.codepro.be (unknown [172.16.1.3])
 by venus.codepro.be (Postfix) with ESMTP id 2C4C820D48;
 Sun,  8 Nov 2015 20:29:52 +0100 (CET)
Received: by vega.codepro.be (Postfix, from userid 1001)
 id 27B244E983; Sun,  8 Nov 2015 20:29:52 +0100 (CET)
Date: Sun, 8 Nov 2015 20:29:52 +0100
From: Kristof Provost <kp@FreeBSD.org>
To: =?utf-8?Q?Mi=C5=82osz?= Kaniewski <milosz.kaniewski@gmail.com>
Cc: freebsd-pf@freebsd.org
Subject: Re: Creating span interface using 'dup-to' option
Message-ID: <20151108192951.GD2336@vega.codepro.be>
References: <CAC4mxp5ar-Kvp5238VRfKEL6FiVOg7XXzmv8fE-zdEFYRk7cAw@mail.gmail.com>
 <SN1PR08MB18210835207E194932EBB485BA310@SN1PR08MB1821.namprd08.prod.outlook.com>
 <CAC4mxp77FrDvT+1J+dQqrgc_ji3vmbMZOkYnXae+D2L1PanK1g@mail.gmail.com>
 <20151108000315.GC2336@vega.codepro.be>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20151108000315.GC2336@vega.codepro.be>
X-Checked-By-NSA: Probably
User-Agent: Mutt/1.5.24 (2015-08-30)
X-BeenThere: freebsd-pf@freebsd.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: "Technical discussion and general questions about packet filter
 \(pf\)" <freebsd-pf.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-pf>,
 <mailto:freebsd-pf-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-pf/>
List-Post: <mailto:freebsd-pf@freebsd.org>
List-Help: <mailto:freebsd-pf-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-pf>,
 <mailto:freebsd-pf-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Nov 2015 19:29:55 -0000

On 2015-11-08 01:03:15 (+0100), Kristof Provost <kp@FreeBSD.org> wrote:
> It certainly looks wrong. I can also reproduce your observation that
> this doesn't happen when 'no state' is added to the rule.
> 
I've been looking at this for a bit, and I think I understand what's
happening now.

With this rule for example:
> pass out on vtnet0 dup-to (vtnet1 10.0.0.1) proto udp from any to any port 53

In short, we hit pf_test() in the output path, match the rule and end up
calling into pf_route(). That's all OK.
pf_route() duplicates the packet and discovers that it's supposed to be
sent out through a different interface (We hit 'if (oifp != ifp)' in
pf_route()) so we run pf_test() again. That's still OK.

In pf_test() we (through pf_test_state_udp()) find state for the
connection and find the rule through the state. As a result we execute
pf_route() a second time, despite the fact that the output interface is
now different. Because we run pf_route() a second time we emit the
packet a second time as well.

I suppose we could mark packets in pf_route() as M_SKIP_FIREWALL, but
that might have other consequences.

I'll need to think about this a bit more.

Regards,
Kristof