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> In-Reply-To: <20151108000315.GC2336@vega.codepro.be> References: <CAC4mxp5ar-Kvp5238VRfKEL6FiVOg7XXzmv8fE-zdEFYRk7cAw@mail.gmail.com> <SN1PR08MB18210835207E194932EBB485BA310@SN1PR08MB1821.namprd08.prod.outlook.com> <CAC4mxp77FrDvT%2B1J%2BdQqrgc_ji3vmbMZOkYnXae%2BD2L1PanK1g@mail.gmail.com> <20151108000315.GC2336@vega.codepro.be>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151108192951.GD2336>