From owner-freebsd-pf@freebsd.org Thu Jun 15 19:47:23 2017 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 201F0B950E2 for ; Thu, 15 Jun 2017 19:47:23 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "smarthost.sentex.ca", Issuer "smarthost.sentex.ca" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E15CF8164E for ; Thu, 15 Jun 2017 19:47:22 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (lava.sentex.ca [IPv6:2607:f3e0:0:5::11]) by smarthost2.sentex.ca (8.15.2/8.15.2) with ESMTPS id v5FJlGRo009834 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 15 Jun 2017 15:47:16 -0400 (EDT) (envelope-from mike@sentex.net) Received: from [192.168.43.26] (saphire3.sentex.net [192.168.43.26]) by lava.sentex.ca (8.15.2/8.15.2) with ESMTP id v5FJlD32092407; Thu, 15 Jun 2017 15:47:14 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: pf logging only no active filtering To: Malte Graebner , freebsd-pf@freebsd.org References: <32bdfeef-fd4a-09d9-d811-4b4b6b24aa15@sentex.net> From: Mike Tancsa Organization: Sentex Communications Message-ID: Date: Thu, 15 Jun 2017 15:47:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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, 15 Jun 2017 19:47:23 -0000 On 6/15/2017 3:32 PM, Malte Graebner wrote: > using quick phrase has the side effect, that Im not able to see, if > there are any packets that would be blocked which shouldn't, because of > not eval the hole ruleset ( about 500 rules ). I am not sure I follow, can you rephrase/state the above ? Do you mean the quick pass rule is not being evaluated, even if its the very first rule ? perhaps illustrate the condition with a minimal set of pf rules? If you dont use the pass in {rdr|binat|nat} and make the quick line the first line, nothing should get evaluated after the quick pass. Also, I would always add 'log' to all the rules when debugging, so you see whats actually being hit. There should not be any mysteries that way. ---Mike > > e.g. : multiple bi directional nat rules , doing not what I expect them > to do. Then I can fix the ruleset, without affecting the live > environment. But therefore I need to process the hole ruleset, to not > get unhandy suprises with some rules when going live. > > > Am 15.06.2017 um 21:18 schrieb Mike Tancsa: >> On 6/15/2017 2:21 PM, Malte Graebner wrote: >>> Hello folks, >>> is there an option, to only log all stuff going on via "log" command and >>> without taking any action to traffic flow itself ? >> Perhaps >> >> pass quick log >> >> ... quick matches and then no longer evals the rules. >> >> ---Mike >> >> > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/