From owner-freebsd-pf@freebsd.org Thu Nov 26 21:11:02 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 DC5FBA3A177 for ; Thu, 26 Nov 2015 21:11:01 +0000 (UTC) (envelope-from milosz.kaniewski@gmail.com) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 904041E18; Thu, 26 Nov 2015 21:11:01 +0000 (UTC) (envelope-from milosz.kaniewski@gmail.com) Received: by vkha189 with SMTP id a189so58901997vkh.2; Thu, 26 Nov 2015 13:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B4pq2A4O2W0cQVsl3TrBEYs2u29Fp+tftjHyPp0c8KI=; b=uAQnEcUizAd1KNg2XO3FoPri45dtCAj7gvkUtsThJpfsq/oMBRMLvMFz1W0F8LiQXP 8oW7FfsTznRIqstNLBWvVZguTie0GioLkkeTxJWLqg+U4BEADTMxQU7No0/q74W+a5nJ 2/Zp+AK5DZQW8hLj+Gw9wlni/Eqa59fqNR3PNTQw66u8CnUa6t3AV17LJSI/DWWJCPpr 8i7aGTMt+AQJvIESHLZyz5lXdG422jHedPIDJpBirLNXnXjEnNvU3QC8zBK70zTBwePR +V+2BOCH37Gt38r/K4DdGuFsZQzQzjs0IMm/XnrQFRCRCHmqixKPudoP1xVPKZC9cB7V 4OTg== MIME-Version: 1.0 X-Received: by 10.31.47.204 with SMTP id v195mr41798783vkv.119.1448572260294; Thu, 26 Nov 2015 13:11:00 -0800 (PST) Received: by 10.31.64.67 with HTTP; Thu, 26 Nov 2015 13:11:00 -0800 (PST) In-Reply-To: <20151122191458.GD2307@vega.codepro.be> References: <20151108000315.GC2336@vega.codepro.be> <20151108192951.GD2336@vega.codepro.be> <20151115173349.GE13268@vega.codepro.be> <20151122191458.GD2307@vega.codepro.be> Date: Thu, 26 Nov 2015 22:11:00 +0100 Message-ID: Subject: Re: Creating span interface using 'dup-to' option From: =?UTF-8?Q?Mi=C5=82osz_Kaniewski?= To: Kristof Provost Cc: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Thu, 26 Nov 2015 21:11:02 -0000 2015-11-22 20:14 GMT+01:00 Kristof Provost : > On 2015-11-15 18:33:49 (+0100), Kristof Provost wrote: > > On the other hand, perhaps there's something we can do about the state > > matching. The problems all start because we match state on the > > duplicated packet. That's not correct, because the rule is set on e.g. > > em0, but the duplicated packet is sent out on em1. > > In fact, from a first reading of the code I don't actually understand > > why we're getting that state match. > > > I've looked at the state matching for a bit. It turns out that by > default packets will match state on any interface (specifically, the > state is saved to the 'all' interface, rather than to the specific > interface it was created on). > That default can be changed with 'set state-policy if-bound'. I'd expect > adding that would work around the problem you see. > Thanks, it did the trick :) I made couple of tests and my dup-to options started to duplicate packets in a right way when I set 'if-bound' policy. I didn't know that it is possible to control packets states policy. At beginning I was surprised that default behaviour is to make states floating between interfaces. But now I think that it can have sense. For example in my case I use pf to forward hundreds of thousands of connections. If I would use floating state policy then I would have as many states as connections. But if I switch to 'if-bound' policy then I would get two times more states than connection= s (one state for original interface and one for interface where packets are duplicated with dup-to). So i think that this workaround is very useful and in many cases it would b= e sufficient. But there are some scenarios, like mine, where floating states could provide big profits and it would be really nice if We could use them. Thank you very much for your help with my problem. Best regards, Mi=C5=82osz