From owner-freebsd-questions@freebsd.org Fri Feb 28 00:16:50 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2F345253EDB for ; Fri, 28 Feb 2020 00:16:50 +0000 (UTC) (envelope-from SRS0=n/vY=4Q=mail.sermon-archive.info=doug@sermon-archive.info) Received: from mail.sermon-archive.info (sermon-archive.info [71.177.216.148]) by mx1.freebsd.org (Postfix) with ESMTP id 48T980281fz4c3n for ; Fri, 28 Feb 2020 00:16:47 +0000 (UTC) (envelope-from SRS0=n/vY=4Q=mail.sermon-archive.info=doug@sermon-archive.info) Received: from [10.0.1.251] (mini [10.0.1.251]) by mail.sermon-archive.info (Postfix) with ESMTPSA id 48T97y6G4Xz2fjRl; Thu, 27 Feb 2020 16:16:46 -0800 (PST) From: Doug Hardie Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: pf usage Date: Thu, 27 Feb 2020 16:16:46 -0800 References: <20200227221511.641d9d91@gumby.homeunix.com> To: RW , RW via freebsd-questions In-Reply-To: <20200227221511.641d9d91@gumby.homeunix.com> Message-Id: <24691027-DA63-4C4B-B851-4C5B3CE2336F@mail.sermon-archive.info> X-Mailer: Apple Mail (2.3445.104.11) X-Virus-Scanned: clamav-milter 0.101.4 at mail X-Virus-Status: Clean X-Rspamd-Queue-Id: 48T980281fz4c3n X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of SRS0=n/vY=4Q=mail.sermon-archive.info=doug@sermon-archive.info designates 71.177.216.148 as permitted sender) smtp.mailfrom=SRS0=n/vY=4Q=mail.sermon-archive.info=doug@sermon-archive.info X-Spamd-Result: default: False [-1.10 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.75)[-0.747,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:71.177.216.148]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.03)[asn: 5650(0.20), country: US(-0.05)]; NEURAL_HAM_LONG(-0.98)[-0.981,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[148.216.177.71.list.dnswl.org : 127.0.10.0]; FORGED_SENDER(0.30)[bc979@lafn.org,SRS0=n/vY=4Q=mail.sermon-archive.info=doug@sermon-archive.info]; FREEMAIL_TO(0.00)[googlemail.com]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5650, ipnet:71.177.216.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[bc979@lafn.org,SRS0=n/vY=4Q=mail.sermon-archive.info=doug@sermon-archive.info]; RCVD_COUNT_TWO(0.00)[2] 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: Fri, 28 Feb 2020 00:16:50 -0000 > On 27 February 2020, at 14:15, RW via freebsd-questions = wrote: >=20 > On Wed, 26 Feb 2020 02:55:15 -0800 > Doug Hardie wrote: >=20 >> I just learned something quite unexpected about pf. Some time ago, >> the rules had to include "state" to have pf track state. However, >> later pf was changed to always assume "state" thus reducing the >> typing of the rules. The description of that change made me believe >> that the change was in pf. On one of my systems with two NICs and >> two different internet providers, I was using pftop to track usage. >> The only states I saw were for just one network. The other one never >> showed any states, but the packets were delivered properly. >>=20 >> I discovered that pf has to have a rule for each interface. I used >> "pass all" for the interface that needed no other rules. The change >> apparently was made to pfctl not pf. So the one interface had no >> rules, and hence there was nothing to tell pf to track state. >=20 > If your concern is to do with efficiency, there may an optimization > there. It's possible that pfctl sets a flag on interfaces that aren't > affected by the rule set, so that traffic can pass with low overheads > and without creating unnecessary state entries. >=20 > I've no idea whether this is correct, it's just speculation. But if it > is then forcing state entries would be counterproductive.=20 In this case, the volume of traffic is quite low. I am much more = concerned about monitoring the connections than in efficiency. I = suspect, though, that your speculation is correct. -- Doug