Re: pfil_default_to_drop

> On Apr 9, 2025, at 1:01 AM, Robert Austen <[email protected]> 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 <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 <[email protected] <mailto:[email protected]>>
> Sent: April 7, 2025 7:55 PM
> To: Robert Austen <[email protected] <mailto:[email protected]>>
> Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; Kristof Provost <[email protected] <mailto:[email protected]>>
> Subject: Re: pfil_default_to_drop
>  
> You don't often get email from [email protected] <mailto:[email protected]>. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>	
> 
> 
>> On Apr 8, 2025, at 6:36 AM, Robert Austen <[email protected] <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>> From: Robert Austen <[email protected] <mailto:[email protected]>>
>> Sent: April 7, 2025 4:33 PM
>> To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>; [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>
>> Subject: Fw: pfil_default_to_drop
>>  
>> 
>> From: Robert Austen
>> Sent: April 7, 2025 4:21 PM
>> To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>
>> 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 <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>