From nobody Wed Apr 9 16:50:24 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 4ZXppr5F2Xz5s3HK; Wed, 09 Apr 2025 16:50:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta004.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXppr0SCKz3xwM; Wed, 09 Apr 2025 16:50:28 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTPS id 2VE7ukkCS5Mqy2Yd8ux14M; Wed, 09 Apr 2025 16:50:26 +0000 Received: from spqr.komquats.com ([70.66.136.217]) by cmsmtp with ESMTPSA id 2Yd6u15p3QwcX2Yd7uzCS7; Wed, 09 Apr 2025 16:50:26 +0000 X-Auth-User: cschuber X-Authority-Analysis: v=2.4 cv=DaW0qetW c=1 sm=1 tr=0 ts=67f6a552 a=h7br+8Ma+Xn9xscxy5znUg==:117 a=h7br+8Ma+Xn9xscxy5znUg==:17 a=kj9zAlcOel0A:10 a=XR8D0OoHHMoA:10 a=6I5d2MoRAAAA:8 a=EkcXrb_YAAAA:8 a=_EeEMxcBAAAA:8 a=UqCG9HQmAAAA:8 a=YxBL1-UpAAAA:8 a=HIpOd3htAAAA:8 a=kUCByv9wAAAA:8 a=HewfmIXYAAAA:8 a=jiAvY12EAAAA:8 a=NMM7OKYrAAAA:8 a=wdBCWTejAAAA:8 a=7deo3vJLAAAA:8 a=SxfSXtOaAAAA:8 a=0VOg8hKvAAAA:8 a=EG9UZMYjAAAA:8 a=Ds8RGfT2AAAA:8 a=E2BN4GkIBzMGMZPVlf4A:9 a=VPyG4jiE2XtzpiXk:21 a=CjuIK1q_8ugA:10 a=iss7NtdUcmcA:10 a=LK5xJRSDVpKd5WXXoEvA:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=kmlo3kNSEkcePd_NiW6t:22 a=bu_5hG6eGWxBxPYBRUjp:22 a=viMdiLGMexgI2yRc-QGl:22 a=vH9twmSOgBVYSauSXlDl:22 a=isrg6BwTYk6I_F0B0DtW:22 a=E6RPhFkzuBHyj9NHzc04:22 a=N19YUjM5w2xS2h45dEdy:22 a=WO70gR-9rc0EB5-JkeQN:22 a=I-efbNKAaAt4Mg394dr-:22 a=amkjWIeD4s3-_WS3cuQ1:22 a=0afPCejbyZHll-xH3H2j:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 130C7E5; Wed, 09 Apr 2025 09:50:24 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 0C165304; Wed, 09 Apr 2025 09:50:24 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Robert Austen cc: Cy Schubert , Zhenlei Huang , "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop In-reply-to: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> <20250409073906.43e4282e@slippy> Comments: In-reply-to Robert Austen message dated "Wed, 09 Apr 2025 16:29:16 -0000." 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 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Apr 2025 09:50:24 -0700 Message-Id: <20250409165024.0C165304@slippy.cwsent.com> X-CMAE-Envelope: MS4xfDC7iwedH6RyvdvsCpiZ0BWPvdsQEjXjDBqGnD8P8NgIvXxpKH/q584fG5w6E9eNsy2GlwNplFEzxIQsEe2j6RIlnfHX3uGNqTCoWxpThpPjyqPJrjqB RmQlWFVA5vrByWNitHGbwgVR00cnBV6bv+9QuDG/mEKvYkZWjX8PiyQ2Dad3vKLdbGuiF63Ob7hrlDN9xRc5dUqZA3lifb7hdAW+fGnjm3WfhK+pxV5kKzqn hsWXthsac82aoFRvKOYojgppTeZxONfiOQt71dYkSnNhrwzcstOsPNcYUTrh3Sb0dtTVaukSiW9vUFRi1Fa138F3pJiwwRDcGtsXZJMbv7a/pUA0d0srLl7X eMMdBhEGseFE43Ygar0rwObXcANZoA== X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Queue-Id: 4ZXppr0SCKz3xwM X-Spamd-Bar: ---- In message , Robert Austen writes: > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > "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 int= > erfaces (esp if static) > came up first, then the forwarding, then pf log, and finally pf was last. Interfaces are started by the netif rc script. I use ipfilter here. netif is started after ipfilter. I had assumed all were the same but apparently not. slippy$ rcorder /etc/rc.d/* | egrep 'ipfilter|netif|pf|ipfw' /etc/rc.d/ipfilter /etc/rc.d/ipfs /etc/rc.d/netif /etc/rc.d/pflog /etc/rc.d/pfsync /etc/rc.d/ipfw /etc/rc.d/ipfw_netflow /etc/rc.d/pf slippy$ We should probably look at moving netif after pf's start. > > 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, a= > nd 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? Agreed. There should always be options. But, what should the default be? Personally, I don't care what the default is. I will set my own options. But most people don't configure their systems as much. Most use the defaults. What works for most people? If default block, then lets do that. > > they shouldn't have to write something to get the result they want (or need= > ), like I had to.. Give people the default and let them change it. I think default block might be preferable. It avoids most people shooting themselves in the foot by not reviewing and changing the default if necessary. Consider most consumers don't change the passwords for their network appliances. Professionals I've worked with do but I'm sure there are many companies where defaults are not reviewed. What offers the average end-user the best protection? Also, what avoids a POLA violation. Balance these two and you will have your answer. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 > > ________________________________ > From: Cy Schubert > Sent: April 9, 2025 8:39 AM > To: Zhenlei Huang > Cc: Robert Austen ; freebsd-current@fr= > eebsd.org ; freebsd-net@freebsd.org et@freebsd.org>; Kristof Provost ; Cy Schubert org> > Subject: Re: pfil_default_to_drop > > [You don't often get email from cy.schubert@cschubert.com. Learn why this i= > s important at https://aka.ms/LearnAboutSenderIdentification ] > > On Wed, 9 Apr 2025 15:48:11 +0800 > Zhenlei Huang wrote: > > > > On Apr 9, 2025, at 1:01 AM, Robert Austen ems.com> wrote: > > > > > > I respectfully disagree. > > > > > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl ca= > ll to enable itself, ie. to apply any hooks. > > > if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaul= > ts 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 ( DIOCST= > ART ) 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 themselve= > s, 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 (a= > nd likewise the equivalents from the other filters). > > > > As for ipfw(4), by default it enables filtering on load, unless you disab= > le 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.in= > et.ip.fw.default_to_accept` controls the default behavior to drop or accept= > . > > See also https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff= > 60e598498df6f9e2bd bbc7fdcff60e598498df6f9e2bd> . > > > > > > > > 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_DEFAU= > LT_TO_DROP, > > > because it handles ALL of the 'no filter installed (yet)' cases. if PFI= > L_DEFAULT_TO_DROP isn't in the kernel config file, my patches have no effec= > t 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 =3D pass all, Logging =3D enabled > IP Filter: v5.1.2 initialized. Default =3D pass all, Logging =3D 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 > > > > Sent: April 7, 2025 7:55 PM > > > To: Robert Austen usten@willowglensystems.com>> > > > Cc: freebsd-current@freebsd.org reebsd-current@freebsd.org >; freebsd-n= > et@freebsd.org ailto:freebsd-net@freebsd.org>>; Kristof Provost @FreeBSD.org>> > > > Subject: Re: pfil_default_to_drop > > > > > > You don't often get email from zlei@freebsd.org g>. Learn why this is important ion> > > > > > > > > >> On Apr 8, 2025, at 6:36 AM, Robert Austen tems.com > wrote: > > >> > > >> > > >> > > >> From: Robert Austen t.austen@willowglensystems.com>> > > >> Sent: April 7, 2025 4:33 PM > > >> To: freebsd-current@freebsd.org <= > freebsd-current@freebsd.org >; freebsd-= > net@freebsd.org mailto: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_D= > ROP and the like, with the observations that it's hard > > >> to ensure that packets all default to drop if the rule file(s) for wha= > tever 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=3Dc531c1d1462c45f7ce5d= > e4f9913226801f3073bd c45f7ce5de4f9913226801f3073bd> . > > > > > >> > > >> After looking thru the online documentation, forums and scripts, I cam= > e 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 ever= > ything thru to its destination. So my thought > > >> was to add an option PFIL_DEFAULT_TO_DROP (in essence a PFIL version o= > f PF_DEFAULT_TO_DROP) that drops all the > > >> IPv4 and IPv6 packets that would otherwise go thru the yet-to-be-loade= > d 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 t= > hink 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 tho= > se hooks untouched. I suppose one could add them, > > >> maybe PFIL_DEFAULT_LOCAL_TO_DROP or PFIL_DEFAULT_LINK_TO_DROP, but I d= > oubt 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 as= > king the above PF questions are closed to changes, > > >> so that doesn't seem a good place. Sir Dice seems to be a common answe= > rer 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 @ne= > w folder. The code was written against FreeBSD-14.1-RELEASE-amd64, > > >> but I suspect the kernel code in the networking core doesn't change mu= > ch 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 > > >> > > >> > > >> > > >> > > >> > > > > > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > > > > > > > >
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; color: rgb(0, 0, 0= > );"> > " t;">Considering that firewall rules are loaded before interfaces" n>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > I don't believe that's true.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > I used rcorder, and played around with things, because I noted that the int= > erfaces (esp if static)
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > came up first, then the forwarding, then pf log, and finally pf was last.&n= > bsp;
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > There are also issue with PF_DEFAULT_TO_DROP, for instance, it breaks "= > ;rdr pass" rules.
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > Anyways, rather than debating what might work better in situation A vs B, a= > nd dictating what
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > users of freeBSD can or cannot do, why not give options? 
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > isn't that the whole point of options and conf files?
>
margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C= > alibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"> > let sysadmin use whatever option they see fit?
>
margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, C= > alibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);"> >
>
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> > they shouldn't have to write something to get the result they want (or need= > ), like I had to..
>
nt, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; c= > olor: rgb(0, 0, 0);"> >
>
>
>
>
yle=3D"font-size:11pt" color=3D"#000000">From: Cy Schubert <Cy.Sc= > hubert@cschubert.com>
> Sent: April 9, 2025 8:39 AM
> To: Zhenlei Huang <zlei@FreeBSD.org>
> Cc: Robert Austen <robert.austen@willowglensystems.com>; freeb= > sd-current@freebsd.org <freebsd-current@freebsd.org>; freebsd-net@fre= > ebsd.org <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBSD.or= > g>; Cy Schubert <cy@freebsd.org>
> Subject: Re: pfil_default_to_drop >
 
>
>
"> >
[You don't often get email from cy.schubert@cschub= > ert.com. Learn why this is important at > https://aka.ms/Le= > arnAboutSenderIdentification ]
>
> On Wed, 9 Apr 2025 15:48:11 +0800
> Zhenlei Huang <zlei@FreeBSD.org> wrote:
>
> > > On Apr 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willo= > wglensystems.com> wrote:
> > >
> > > I respectfully disagree.
> > >
> > > PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its io= > ctl 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_DEFAU= > LT_TO_DROP.
> >
> > Ahh, I see your problem. Yes, you're right. pf(4) requires ioctl ( DIO= > CSTART ) 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 the= > mselves, the pfil layer in the kernel has no idea what the filter will be,<= > br> > > > assuming there even is one. thus PF_DEFAULT_TO_DROP  has zer= > o effect (and likewise the equivalents from the other filters).
> >
> > As for ipfw(4), by default it enables filtering on load, unless you di= > sable it via loader tunable `net.inet.ip.fw.enable`, `net.inet6.ip6.fw.enab= > le` 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 acc= > ept.
> > See also 4db5ebbc7fdcff60e598498df6f9e2bd"> > https://cgit.freebsd.org/src/commit/?id=3D5f17ebf94db5ebbc7fdcff60e598498df= > 6f9e2bd < f94db5ebbc7fdcff60e598498df6f9e2bd">https://cgit.freebsd.org/src/commit/?id= > =3D5f17ebf94db5ebbc7fdcff60e598498df6f9e2bd> > .
> >
> > >
> > > as I said, this is because there's no mechanism within PFIL to dr= > op 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_DEFAU= > LT_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 n= > ot 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 =3D pass all, Logging =3D enab= > led
> IP Filter: v5.1.2 initialized.  Default =3D pass all, Logging =3D enab= > led
> 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 <zlei@FreeBSD.org < ei@FreeBSD.org">mailto:zlei@FreeBSD.org>>
> > > Sent: April 7, 2025 7:55 PM
> > > To: Robert Austen <robert.austen@willowglensystems.com < href=3D"mailto:robert.austen@willowglensystems.com">mailto:robert.austen@wi= > llowglensystems.com>>
> > > Cc: freebsd-current@freebsd.org < rent@freebsd.org">mailto:freebsd-current@freebsd.org> <freebsd-cu= > rrent@freebsd.org <mailto= > :freebsd-current@freebsd.org>>; freebsd-net@freebsd.org > <mailto:freebsd-net@freebsd.= > org> <freebsd-net@freebsd.org < reebsd.org">mailto:freebsd-net@freebsd.org>>; Kristof Provost <= > ;kp@FreeBSD.org <mailto:kp@FreeBSD.org= > >>
> > > Subject: Re: pfil_default_to_drop
> > >
> > > You don't often get email from zlei@freebsd.org < ilto:zlei@freebsd.org">mailto:zlei@freebsd.org>. Learn why this is i= > mportant <http= > s://aka.ms/LearnAboutSenderIdentification>
> > >
> > >
> > >> On Apr 8, 2025, at 6:36 AM, Robert Austen <robert.austen@w= > illowglensystems.com < com">mailto:robert.austen@willowglensystems.com>> wrote:
> > >>
> > >>
> > >>
> > >> From: Robert Austen <robert.austen@willowglensystems.com &= > lt;mailto:robert.aus= > ten@willowglensystems.com>>
> > >> Sent: April 7, 2025 4:33 PM
> > >> To: freebsd-current@freebsd.org < -current@freebsd.org">mailto:freebsd-current@freebsd.org> <freebs= > d-current@freebsd.org <ma= > ilto:freebsd-current@freebsd.org>>; freebsd-net@freebsd.org > <mailto:freebsd-net@freebsd.= > org> <freebsd-net@freebsd.org < reebsd.org">mailto: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 < -current@freebsd.org">mailto:freebsd-current@freebsd.org> <freebs= > d-current@freebsd.org <ma= > ilto:freebsd-current@freebsd.org>>
> > >> Subject: pfil_default_to_drop
> > >>
> > >> Hello,
> > >> I've been playing with FreeBSD and PF to build myself a new f= > irewall, as Open/FreeBSD + PF seems to be a common starting point.
> > >>
> > >> I've noticed a number of people asking questions about PF_DEF= > AULT_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 pr= > eload pf.ko ( via the loader(8), /boot/loader.conf ) ?
> > >
> > > With 13.5, or upcoming 14.3 ( you can also experiment latest stab= > le/14 ), you can turn the loader tunable net.pf.default_to_drop to 1, and p= > reload pf.ko.
> > > See also 1c1d1462c45f7ce5de4f9913226801f3073bd"> > https://cgit.freebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801= > f3073bd < d1462c45f7ce5de4f9913226801f3073bd">https://cgit.freebsd.org/src/commit/?id= > =3Dc531c1d1462c45f7ce5de4f9913226801f3073bd> > .
> > >
> > >>
> > >> After looking thru the online documentation, forums and scrip= > ts, 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 p= > roblem 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 s= > ends 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 t= > hreads asking the above PF questions are closed to changes,
> > >> so that doesn't seem a good place. Sir Dice seems to be a com= > mon 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 co= > py 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.Schubert@cschubert.com>
> FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  =3D"https://FreeBSD.org">https://FreeBSD.org
> NTP:           <cy@nwt= > ime.org>    Web:  htt= > ps://nwtime.org
>
>             &nb= > sp;           e^(i*pi)+1= > =3D0
>
>
> > > > --_000_QB1PPF4C719E46AAEE7D88923E46E08C427EFB42QB1PPF4C719E46A_--