From owner-freebsd-pf@freebsd.org Sun Nov 8 00:03:19 2015 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 9BD72A28B57 for ; Sun, 8 Nov 2015 00:03:19 +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 5F0771294 for ; Sun, 8 Nov 2015 00:03:18 +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 7341D2046A; Sun, 8 Nov 2015 01:03:15 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 69BC84E7DF; Sun, 8 Nov 2015 01:03:15 +0100 (CET) Date: Sun, 8 Nov 2015 01:03:15 +0100 From: Kristof Provost To: =?utf-8?Q?Mi=C5=82osz?= Kaniewski Cc: freebsd-pf@freebsd.org Subject: Re: Creating span interface using 'dup-to' option Message-ID: <20151108000315.GC2336@vega.codepro.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 00:03:19 -0000 On 2015-11-07 21:36:28 (+0100), Miłosz Kaniewski wrote: > 2015-10-12 16:28 GMT+02:00 David DeSimone : > But unfortunately I still have a problem with 'dup-to' option. I hope you > don't > mind if I will describe it here, as it is still connected with network > scheme I > used in my first post. > > As I explained 'dup-to' option is useful only when it is used with next-hop > parameter. So in my configuration from first post I made these changes: > > pass out on em0 dup-to (em2 10.0.0.1) no state > pass out on em1 dup-to (em2 10.0.0.1) no state > > IP address 10.0.0.1 is accessible through em2 interface. And with that > configuration everything works fine and duplicated packets are send through > em2 > interface without any problems. But I tried to make a little change and used > one stateful rule: > > pass out on em1 dup-to (em2 10.0.0.1) > > And with that configuration something strange is happening. Packets are > still > duplicated and correctly sent through em2 interface but there are too much > of > them. It looks like some of the packets are duplicated to many times. Lets > say > I send ICMP ping that goes through em1. On em2 i should see two packets: > ICMP > request and ICMP reply. But I see two identical ICMP requests and one ICMP > reply. So there are 3 packets instead of two. Yeah, I see the same thing in my test setup. I'll try to investigate it soon. > I don't want to fill bug report yet. First I would like to hear your opinion > about this behaviour. And it would be great if someone would check similar > situation and confirm that this problem really exists. > It certainly looks wrong. I can also reproduce your observation that this doesn't happen when 'no state' is added to the rule. Regards, Kristof From owner-freebsd-pf@freebsd.org Sun Nov 8 19:29:55 2015 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 447CDA29382 for ; 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 ; 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 To: =?utf-8?Q?Mi=C5=82osz?= Kaniewski Cc: freebsd-pf@freebsd.org Subject: Re: Creating span interface using 'dup-to' option Message-ID: <20151108192951.GD2336@vega.codepro.be> References: <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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Nov 2015 19:29:55 -0000 On 2015-11-08 01:03:15 (+0100), Kristof Provost 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