"Considering that firewall rules are loaded before interfaces" I don't believe that's true.
I used rcorder, and played around with things, because I noted that the interfaces (esp if static) came up first, then the forwarding, then pf log, and finally pf was last. There are also issue with PF_DEFAULT_TO_DROP, for instance, it breaks "rdr pass" rules. Anyways, rather than debating what might work better in situation A vs B, and dictating what users of freeBSD can or cannot do, why not give options? isn't that the whole point of options and conf files? let sysadmin use whatever option they see fit? they shouldn't have to write something to get the result they want (or need), like I had to.. ________________________________ From: Cy Schubert <cy.schub...@cschubert.com> Sent: April 9, 2025 8:39 AM To: Zhenlei Huang <z...@freebsd.org> Cc: Robert Austen <robert.aus...@willowglensystems.com>; 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 cy.schub...@cschubert.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] On Wed, 9 Apr 2025 15:48:11 +0800 Zhenlei Huang <z...@freebsd.org> wrote: > > On Apr 9, 2025, at 1:01 AM, Robert Austen > > <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 > > <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. I don't know whether it should default drop or not. In the case of ipfilter, default drop will drop with or without a log message depending whether IPFILTER_LOG is defined in the kernel config or in the module's Makefile -- both are default. There's something to be said about default block in that there is absolutely no chance any packets will get through without a rule permitting them. OTOH, the packet filters (PF, IPFW, IPF) are enabled and loaded before any interfaces are brought up so the point is mostly moot. However in unattended situations there is a better chance you could be able to remotely log in to fix any brokenness whereas with a default block you'd have to travel, possibly thousands of kilometres, to fix any problem. Both scenarios should be considered before making the decision whether to default block or default open. Then again, a badly conceived firewall rule, regardless of the default block setting, can make for a very bad day. IIRC -- it's been a couple of decades since I used IPFW -- IPFW is default block while IPFILTER is default open (unless otherwise configured). Considering that firewall rules are loaded before interfaces are brought up -- just run rcorder(8) to see the startup order for yourself -- this argument is moot. > > 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). This is not entirely correct. If IPFILTER_DEFAULT_BLOCK is defined IPF will block by default. Otherwise by default it will not block by default. This can be adjusted at runtime in two ways. First through the sysctl net.inet.ipf.ipf_pass and alternatively through ipf -T default_pass. The value is not intuitive. It's a hex value representing internal flags. If the hex value contains 0x2, ipfilter operates in default pass mode. If the hex value contains 0x1, it operates in default block mode. It will tell you at boot which mode is default: stinky# dmesg | grep IP\ Filter IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled IP Filter: v5.1.2 initialized. Default = pass all, Logging = enabled stinky# Though the sysctl net.inet.ipf.ipf_pass exists, using ipf -T default_pass to adjust the flag is preferred. Setting the default_block or ipf_pass is not entirely intuitive. > > > > > 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 > > > > <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> > > > -- Cheers, Cy Schubert <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0
