From nobody Wed Apr 9 07:48:11 2025 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4ZXZnG74qXz5shdp; Wed, 09 Apr 2025 07:48:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R11" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXZnG6SPlz3RDn; Wed, 09 Apr 2025 07:48:18 +0000 (UTC) (envelope-from zlei@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744184898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Bve4yGyu1TEMucTKSXCLe+oUkHpkIsJ6geY6aVTZJOU=; b=qLc7VHSQaqMzzuw0rgG/ZuZWtwNnGcuhZQu+XkEHKKq6KJVlH+NerftE5e5hyDv7O/toTs Wq8x7d0XmLBDP7/kXqTBGBRI1tdBMCI+Wx7p03SBF7i+OO77wE8GVyDU8nit4uZ8KBxlyy b6de3ZujSmLQinC4TLcMmCZAfrEIOwNdPGGiNKfPVju/YB7XxJF7NFliXFC9aIiy+dtulF 30iRbrrySMvgPjbGVlmp3y4XIV0aGo3MA85CfP7jMtMFAsSLn9uFkFbharoGCNTZfMQInp 1iRikEIJ5Fe6a8w9SoZUoJWDeocENiha5kpgxm6br/dIy/HfgEOfRiqYmaZ9Bg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1744184898; a=rsa-sha256; cv=none; b=XaoUtN0cXUoD0tqqOOJKZ61uayd7OVJIHUxxyNTlPGZwloYx+wmKz7oZmHDevuPl8o/mcD vo9EAYaptB5s1wp1TMD8XVrK87BEIsXdutTTQLw1Idln/kCID4i86ZrEyZfLh9nFD1riDy fqgllBgf575OIfm4Wsg+7mkLPAscikg+dmVrMK10E2m77GeZ209nFhXW0wWBIfCA5qr+MQ N/9FXXtEOFurcq1M/3eXykhoUCRdpUmzqhqRCtKISB4+elM5BRY8OSozzqBPY47mps7iOc vVag6KHmEn1TPkriCiwjqm/sSuhiSwGWeyTWpwKO7unCl+41WV7CA8EVkwUaMg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1744184898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Bve4yGyu1TEMucTKSXCLe+oUkHpkIsJ6geY6aVTZJOU=; b=AWtokODFPtxgp+r+4SU4rcMkwngcNDvxkRepCTml+SLJaUionrhJ40WXOmn3K/WpfGT6kB psGhuv8PeWCUrY9G62OJ87JK9peVFHjtqtjq2GXNyPdK3ilUedblbgqJTQ50FWHuvyQ0XZ qI+oGjU0Kh4MPHFVlCRHXcj8FX0Bbhuqdvf9sES41nkHDFhksQzPp+yGukeHllsBzT8yxx uchcwlLK/sEYffTjmEp5EvDgRoITpm/v/LMAtNMazS6IOzTODlvDmOudGZL2vuuq0uu8n0 ChUdjKeDZPhIs+OLNzYriAoaBfgIbIkBJp56CwAyM9bB685mLnB6W0czt/YZ4g== Received: from smtpclient.apple (ns1.oxydns.net [45.32.91.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: zlei/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4ZXZnD5CwFz53k; Wed, 09 Apr 2025 07:48:16 +0000 (UTC) (envelope-from zlei@FreeBSD.org) From: Zhenlei Huang Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE" List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\)) Subject: Re: pfil_default_to_drop Date: Wed, 9 Apr 2025 15:48:11 +0800 In-Reply-To: Cc: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert To: Robert Austen References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> X-Mailer: Apple Mail (2.3696.120.41.1.10) --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 9, 2025, at 1:01 AM, Robert Austen = wrote: >=20 > I respectfully disagree. >=20 > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl = call to enable itself, ie. to apply any hooks. > if pfctl fails, then the hooks are left unhooked, and EVERYTHING = defaults to PASS, which is not what most people would intend using = PF_DEFAULT_TO_DROP. Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( = DIOCSTART ) or netlink command to enable it. @Kristof Maybe we also want a loader tunable to enable pf(4) on load ? >=20 > consider this: until pf or ipf or ipfw makes an ioctl to hook = themselves, the pfil layer in the kernel has no idea what the filter = will be, > assuming there even is one. thus PF_DEFAULT_TO_DROP has zero effect = (and likewise the equivalents from the other filters). As for ipfw(4), by default it enables filtering on load, unless you = disable it via loader tunable `net.inet.ip.fw.enable`, = `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`. The compile option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable = `net.inet.ip.fw.default_to_accept` controls the default behavior to drop = or accept. See also = https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60e598498d= f6f9e2bd = . >=20 > as I said, this is because there's no mechanism within PFIL to drop by = default, which is why I proposed (and am using on my system) the = PFIL_DEFAULT_TO_DROP, > because it handles ALL of the 'no filter installed (yet)' cases. if = PFIL_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no = effect at all, > so it's a simple mechanism for those that want more than = PF_DEFAULT_TO_DROP can ever provide. It appears ipf(4) unconditionally enable filtering on load, and does not = have any tunables to control that. CC @Cy who is more familiar with = ipf(4). >=20 > thanks! > From: Zhenlei Huang > > Sent: April 7, 2025 7:55 PM > To: Robert Austen > > Cc: freebsd-current@freebsd.org = >; = freebsd-net@freebsd.org = >; Kristof = Provost > > Subject: Re: pfil_default_to_drop > =20 > You don't often get email from zlei@freebsd.org = . Learn why this is important = =09 >=20 >=20 >> On Apr 8, 2025, at 6:36 AM, Robert Austen = > wrote: >>=20 >>=20 >>=20 >> From: Robert Austen > >> Sent: April 7, 2025 4:33 PM >> To: freebsd-current@freebsd.org = >; = freebsd-net@freebsd.org = > >> Subject: Fw: pfil_default_to_drop >> =20 >>=20 >> From: Robert Austen >> Sent: April 7, 2025 4:21 PM >> To: freebsd-current@freebsd.org = > >> Subject: pfil_default_to_drop >> =20 >> Hello, >> I've been playing with FreeBSD and PF to build myself a new firewall, = as Open/FreeBSD + PF seems to be a common starting point. >>=20 >> I've noticed a number of people asking questions about = PF_DEFAULT_TO_DROP and the like, with the observations that it's hard >> to ensure that packets all default to drop if the rule file(s) for = whatever reason fail to load.=20 >=20 > Hi Robert, >=20 > So why not defining the compile option PF_DEFAULT_TO_DROP, and preload = pf.ko ( via the loader(8), /boot/loader.conf ) ? >=20 > With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 = ), you can turn the loader tunable net.pf.default_to_drop to 1, and = preload pf.ko. > See also = https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f991322680= 1f3073bd = . >=20 >>=20 >> After looking thru the online documentation, forums and scripts, I = came to the conclusion that it's not a PF problem or IPFW etc >> or really a problem with any of the filters or scripts, the problem = is at the level of PFIL, the kernel packet filtering code: If no >> filter is loaded, i.e. if the heads are unhooked, then PFIL sends = everything thru to its destination. So my thought=20 >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version = of PF_DEFAULT_TO_DROP) that drops all the >> IPv4 and IPv6 packets that would otherwise go thru the = yet-to-be-loaded chosen filter (PF or whatever) at any given time the=20 >> hooks are unhooked.=20 >=20 > If no firewalls loaded, then the system should behave as is. I do not = think PFIL_DEFAULT_TO_DROP is the right way to handle your case. >=20 >>=20 >> [No one filters on local loopback nor the link layer, so I've left = those hooks untouched. I suppose one could add them, >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I = doubt there's much demand for it.] >>=20 >> Normally I'm an embedded linux kernel basher. >> I'm not entirely sure where to send this patch. Most of the threads = asking the above PF questions are closed to changes, >> so that doesn't seem a good place. Sir Dice seems to be a common = answerer of questions; I would have sent it to him/her=20 >> if I could... >>=20 >> I'm not a user of GIT, so I'm not sure how to submit a "GIT formatted = patch"... >> I've simply diff -rdpNU 5 a copy of the @old folder with a copy of = @new folder. The code was written against FreeBSD-14.1-RELEASE-amd64, >> but I suspect the kernel code in the networking core doesn't change = much from platform to platform, or version to version. >>=20 >> But it works, it's pretty simple, pretty small and so just in case it = might be useful, I'm passing it along. >>=20 >> thanks! >>=20 >>=20 >> Robert >>=20 >>=20 >>=20 >>=20 >> --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willowglensystems.com> wrote:

I respectfully disagree.

PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its = ioctl call to enable itself, ie. to apply any hooks.
if pfctl fails, then = the hooks are left unhooked, and EVERYTHING defaults to PASS, which is = not what most people would intend using = PF_DEFAULT_TO_DROP.

Ahh, I see your problem. Yes, you're right. pf(4) = requires ioctl ( DIOCSTART ) or netlink command to enable = it.

@Kristof Maybe we also want a = loader tunable to enable pf(4) on load ?


consider this: until = pf or ipf or ipfw makes an ioctl to hook themselves, the pfil layer in = the kernel has no idea what the filter will be,
assuming there even is = one. thus PF_DEFAULT_TO_DROP  has zero effect (and likewise the = equivalents from the other filters).

As for ipfw(4), by default it enables filtering on = load, unless you disable it via loader tunable `net.inet.ip.fw.enable`, = `net.inet6.ip6.fw.enable` and `net.link.ether.ipfw`.

The compile = option IPFIREWALL_DEFAULT_TO_ACCEPT or loader tunable = `net.inet.ip.fw.default_to_accept` controls the default behavior to drop = or accept.


as I said, this is = because there's no mechanism within PFIL to drop by default, which is = why I proposed (and am using on my system) the = PFIL_DEFAULT_TO_DROP,
because it handles ALL of the 'no filter = installed (yet)' cases. if PFIL_DEFAULT_TO_DROP isn't in the kernel = config file, my patches have no effect at all,
so it's a simple = mechanism for those that want more than PF_DEFAULT_TO_DROP can ever = provide.

It = appears ipf(4) unconditionally enable filtering on load, and does not = have any tunables to control that. CC @Cy who is more familiar with = ipf(4).


thanks!
From: Zhenlei Huang <zlei@FreeBSD.org>
Sent: April 7, 2025 7:55 PM
To: Robert Austen <robert.austen@willowglensystems.com>
Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBSD.org>
Subject: Re: = pfil_default_to_drop
 
You don't often get email from zlei@freebsd.org. Learn why this is important


On Apr 8, 2025, at 6:36 AM, = Robert Austen <robert.austen@willowglensystems.com> wrote:



From: Robert Austen <robert.austen@willowglensystems.com>
Sent: April 7, 2025 4:33 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@freebsd.org <freebsd-net@freebsd.org>
Subject: Fw: pfil_default_to_drop
 

From: Robert Austen
Sent: April 7, 2025 4:21 PM
To: freebsd-current@freebsd.org <freebsd-current@freebsd.org>
Subject: pfil_default_to_drop
 
Hello,
I've been playing with FreeBSD = and PF to build myself a new firewall, as Open/FreeBSD + PF seems to be = a common starting point.

I've noticed a number of people = asking questions about PF_DEFAULT_TO_DROP and the like, with the = observations that it's hard
to ensure that packets all default to drop if the rule file(s) = for whatever reason fail to load. 

Hi Robert,

So why not defining the = compile option PF_DEFAULT_TO_DROP, and preload pf.ko ( via the loader(8), /boot/loader.conf ) ?

With 13.5, or upcoming 14.3 ( you can also experiment = latest stable/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, = and preload pf.ko.
See = also https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de= 4f9913226801f3073bd .


After looking thru the online documentation, forums = and scripts, I came to the conclusion that it's not a PF problem or IPFW = etc
or really a problem with any of the = filters or scripts, the problem is at the level of PFIL, the kernel = packet filtering code: If no
filter is loaded, i.e. if the heads are unhooked, then PFIL = sends everything thru to its destination. So my = thought 
was to add an option = PFIL_DEFAULT_TO_DROP (in essence a PFIL version of PF_DEFAULT_TO_DROP) = that drops all the
IPv4 and IPv6 packets that = would otherwise go thru the yet-to-be-loaded chosen filter (PF or = whatever) at any given time the 
hooks are  = unhooked. 

If no firewalls loaded, then the system = should behave as is. I do not think PFIL_DEFAULT_TO_DROP is the = right way to handle your case.


[No one filters on local loopback nor the link layer, = so I've left those hooks untouched. I suppose one could add = them,
maybe = PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I doubt = there's much demand for it.]

Normally I'm an embedded linux = kernel basher.
I'm not entirely sure where to send this patch. Most of the = threads asking the above PF questions are closed to changes,
so that doesn't seem a good = place. Sir Dice seems to be a common answerer of questions; I would have = sent it to him/her 
if I could...

I'm not a user of GIT, so I'm = not sure how to submit a "GIT formatted patch"...
I've simply diff -rdpNU 5 a copy of the @old folder = with a copy of @new folder. The code was written against = FreeBSD-14.1-RELEASE-amd64,
but I suspect the kernel code in the networking core doesn't = change much from platform to platform, or version to version.

But it works, it's pretty = simple, pretty small and so just in case it might be useful, I'm passing = it along.

thanks!


Robert




<FreeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip&g= t;


= --Apple-Mail=_26061429-F0E0-4E6E-861C-1085C0A47FDE--