"Maybe we also want a loader tunable to enable pf(4) on load" Seems a complicated way to do a simple thing. imho.
Did you happen to look at my tiny patch? There are already a bunch of macros (PFIL_HOOKED_IN, PFIL_HOOKED_OUT) defined depending on the inclusion of INET v4 or 6. I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the HOOKED_ one, or FALSE when INET v4 or 6 is excluded or if PFIL_DEFAULT_TO_DROP isn't defined. Then whereever the existing PFIL_HOOKED_IN/OUT_46 macros are used, prior to calling the filter hook, I just inserted a PFIL_UNHOOKED_IN/OUT_46 check, and a 'goto drop' instead of the 'goto passin/out' for the 7 occurances in if_gateway and the 3 in the NETINET code (ip_input, ip_output, ip_fastfwd) and the 4 in the NETINET6 code (same as netinet4 plus ip6_foward). easy peasy. I spend 10x more time messing with the kernel Makefile + CONF structure than with my changes lol. ________________________________ From: Zhenlei Huang <z...@freebsd.org> Sent: April 9, 2025 1:48 AM To: Robert Austen <robert.aus...@willowglensystems.com> Cc: freebsd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-...@freebsd.org <freebsd-...@freebsd.org>; Kristof Provost <k...@freebsd.org>; Cy Schubert <c...@freebsd.org> Subject: Re: pfil_default_to_drop You don't often get email from z...@freebsd.org. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.aus...@willowglensystems.com<mailto:robert.aus...@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. See also https://cgit.freebsd.org/src/commit/?id=5f17ebf94db5ebbc7fdcff60e598498df6f9e2bd . 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 <z...@freebsd.org<mailto:z...@freebsd.org>> Sent: April 7, 2025 7:55 PM To: Robert Austen <robert.aus...@willowglensystems.com<mailto:robert.aus...@willowglensystems.com>> Cc: freebsd-current@freebsd.org<mailto:freebsd-current@freebsd.org> <freebsd-current@freebsd.org<mailto:freebsd-current@freebsd.org>>; freebsd-...@freebsd.org<mailto:freebsd-...@freebsd.org> <freebsd-...@freebsd.org<mailto:freebsd-...@freebsd.org>>; Kristof Provost <k...@freebsd.org<mailto:k...@freebsd.org>> Subject: Re: pfil_default_to_drop You don't often get email from z...@freebsd.org<mailto:z...@freebsd.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.aus...@willowglensystems.com<mailto:robert.aus...@willowglensystems.com>> wrote: ________________________________ From: Robert Austen <robert.aus...@willowglensystems.com<mailto:robert.aus...@willowglensystems.com>> Sent: April 7, 2025 4:33 PM To: freebsd-current@freebsd.org<mailto:freebsd-current@freebsd.org> <freebsd-current@freebsd.org<mailto:freebsd-current@freebsd.org>>; freebsd-...@freebsd.org<mailto:freebsd-...@freebsd.org> <freebsd-...@freebsd.org<mailto:freebsd-...@freebsd.org>> Subject: Fw: pfil_default_to_drop ________________________________ From: Robert Austen Sent: April 7, 2025 4:21 PM To: freebsd-current@freebsd.org<mailto:freebsd-current@freebsd.org> <freebsd-current@freebsd.org<mailto: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=c531c1d1462c45f7ce5de4f9913226801f3073bd . 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>
