From owner-freebsd-questions@freebsd.org Mon Feb 11 17:50:06 2019 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B1CB14DEE72 for ; Mon, 11 Feb 2019 17:50:06 +0000 (UTC) (envelope-from byrnejb@harte-lyne.ca) Received: from mx32.harte-lyne.ca (mx32.harte-lyne.ca [216.185.71.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx32.harte-lyne.ca", Issuer "CA_HLL_ISSUER_2016" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C8DA581F14; Mon, 11 Feb 2019 17:49:55 +0000 (UTC) (envelope-from byrnejb@harte-lyne.ca) Received: from mx32.harte-lyne.ca (unknown [127.0.32.1]) by mx32.harte-lyne.ca (Postfix) with ESMTP id C4EFC10069; Mon, 11 Feb 2019 12:49:49 -0500 (EST) X-Virus-Scanned: amavisd-new at harte-lyne.ca Received: from mx32.harte-lyne.ca ([127.0.32.1]) by mx32.harte-lyne.ca (mx32.harte-lyne.ca [127.0.32.1]) (amavisd-new, port 10024) with ESMTP id 4-dZNa7Uwdha; Mon, 11 Feb 2019 12:49:48 -0500 (EST) Received: from webmail.harte-lyne.ca (mx32.harte-lyne.ca [216.185.71.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx32.harte-lyne.ca (Postfix) with ESMTPSA id B184B10060; Mon, 11 Feb 2019 12:49:47 -0500 (EST) Received: from 216.185.71.44 (SquirrelMail authenticated user byrnejb_hll) by webmail.harte-lyne.ca with HTTP; Mon, 11 Feb 2019 12:49:47 -0500 Message-ID: <84e067c2d768e3fa7e1d090ab9c33418.squirrel@webmail.harte-lyne.ca> In-Reply-To: References: Date: Mon, 11 Feb 2019 12:49:47 -0500 Subject: Re: pf filter settings From: "James B. Byrne" To: freebsd-questions@freebsd.org Reply-To: byrnejb@harte-lyne.ca User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Rspamd-Queue-Id: C8DA581F14 X-Spamd-Bar: -------- X-Spamd-Result: default: False [-8.48 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[byrnejb@harte-lyne.ca]; RBL_COMPOSITE_RCVD_IN_DNSWL_MED_DWL_DNSWL_LOW(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.185.71.0/26]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; DKIM_TRACE(0.00)[harte-lyne.ca:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[32.71.185.216.list.dnswl.org : 127.0.4.2]; DMARC_POLICY_ALLOW(-0.50)[harte-lyne.ca,quarantine]; MX_GOOD(-0.01)[mx32.harte-lyne.ca,mx31.harte-lyne.ca,mx132.harte-lyne.ca]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:12021, ipnet:216.185.64.0/20, country:CA]; IP_SCORE(-3.78)[ip: (-9.91), ipnet: 216.185.64.0/20(-4.95), asn: 12021(-3.96), country: CA(-0.09)]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[harte-lyne.ca:s=dkim_hll]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(0.00)[harte-lyne.ca.dwl.dnswl.org : 127.0.4.1]; NEURAL_HAM_SHORT(-0.99)[-0.986,0] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 17:50:06 -0000 On Wed, February 6, 2019 10:50, Matthew Seaman wrote: > On 06/02/2019 14:48, James B. Byrne via freebsd-questions wrote: >> What is going on? Why is the rule 'block drop in log all' >> have effect and the rule >> >> pass log quick on $int_if \ >> from { self $int_if:network } \ >> to { self $int_if:network } >> >> does not, despite the quick option and the fact that it occurs >> first. > > Because pf always applies the *last* matching rule. It's the opposite > way round to ipfw(8). The 'quick' option is suppose to pre-empt the default behaviour. > > In general, you want to order your pf ruleset from the most general to > the most specific. You can short-circuit searching the whole ruleset > by using the 'quick' modifier -- use this on early and more general > rules to weed out the obviously wrong traffic. Which did not have the expected effect in this case. > > Also, read the docco on: > > set skip on { $int_if } > > which should achieve what you you want (assuming that you're only > logging traffic on that i/f as a debugging thing.) > I did that as a workaround whilst investigating the source of the difficulty. Which appears to turn on the difference between implementations of the network stack on Linux and FreeBSD and my general ignorance about things network beyond the superficial. I have not acquired enough knowledge to explain what is going on but the treatment of packets arriving from differing subnets on the same interface seems to be the critical element. Because the packets appear to arrive from differing networks than the destination they considered they are treated differently than those appearing from and going to the same network even when both arrive and depart on the same interface. Which they have to because there is only one internal i/f to use. This differs from the default behaviour of CentOS that I am most familiar with. I am still trying understand what that difference is exactly. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB@Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3