From nobody Wed Apr 09 16:44:17 2025 X-Original-To: freebsd-current@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 4ZXpgw30s2z5s3CK; Wed, 09 Apr 2025 16:44:28 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Received: from YT5PR01CU002.outbound.protection.outlook.com (mail-canadacentralazon11021081.outbound.protection.outlook.com [40.107.192.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZXpgv5LQ5z3vCD; Wed, 09 Apr 2025 16:44:27 +0000 (UTC) (envelope-from robert.austen@willowglensystems.com) Authentication-Results: mx1.freebsd.org; none ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=s3JKPUPYAgQyWFgmJsqCWyANaQ63SCmbLmUx+4KXv+HFSQPCg9UeSdat8w8tUMLDRuQp/ZguiZknvTJwjaEGnFjtGQeIOoCLerQhYMJgq115mV+zf68znlrSYnlHoBlsYuijyl7bi6MUW8ZjkbBNLjNiZ/W0ooYjO5o9W9lZV09UP1we+MgLEFg0ezEbOuNy+r/oE08p5uXCXchc6lHrMxvrW1Vth11X+xdiv/LWUNE8aXnwq8PQfuwmx94EsTTJdeKNsh+GOFIpR0Dro06ub0MWBEVKwvgr7hXbKgw/MKHTUnUFrEWOJ4wWDkt82Pcao0kem3VL89ZSCFeqaDJQ8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KjxL44mRjYwy39XSbisW0rm3bJJv4eJ9/xA6l5X9rRc=; b=JRQPmv5Y+JGkr6ZyQrL/yC5EjHTkn+8yHbbsG9hJnOmspjUQ+zL7DF0JFNzuVgqufdxNVj0xARkWZITdAgGGxMICniHueFTj3boP6AUrsGYFWJXhq2Tmx2Tmz5nkRXxFruSwiqAXE54TD7ulbnFspQNUtnPfAqRa8dQvoptgv5PIpv1++N8DP6vcxNLGKEIlxHHRrME3c8atPzxFYApq4kZteQRzhj47Tjvoxq8a/DY9+XLBPmrqjkJZ2jLkRzseV0zoj0t0RCxQSdV9sz8g+N2cxJaVfd5rpuWU8KZrt7H0JaYrIdrLB9fcQTc98z5SMcReg2DkdK5/M6+b9O+1Cg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=willowglensystems.com; dmarc=pass action=none header.from=willowglensystems.com; dkim=pass header.d=willowglensystems.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=willowglensystems.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KjxL44mRjYwy39XSbisW0rm3bJJv4eJ9/xA6l5X9rRc=; b=m6EmaGOimS06se5v/K5y/TMEQodprywTqVe13sq0i7F7KeoczVqqQ2SAeloyypCoeZds3pn1NXCxmAc5XgHO177CAM86/ABa+w+lrKcDKzseUGgSvyYPrge4PMrYAVPueFmfoScTFDmP8nGY3cfMwr2EDR5iegRIhi2jd1VDIKI= Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c08::23a) by YT2PR01MB8422.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:b1::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.8606.35; Wed, 9 Apr 2025 16:44:17 +0000 Received: from QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d]) by QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM ([fe80::cd61:75c:8fac:109d%4]) with mapi id 15.20.8632.021; Wed, 9 Apr 2025 16:44:17 +0000 From: Robert Austen To: Zhenlei Huang CC: "freebsd-current@freebsd.org" , "freebsd-net@freebsd.org" , Kristof Provost , Cy Schubert Subject: Re: pfil_default_to_drop Thread-Topic: pfil_default_to_drop Thread-Index: AQHbqAfyk4Z18yjsM0yECEK2f5QGrrOYyea/gAAA4zGAADehgIAA+tGKgAD6MICAAJOZqA== Date: Wed, 9 Apr 2025 16:44:17 +0000 Message-ID: References: <274BB159-3CB5-49E0-84E7-A3F4B81BFDC1@FreeBSD.org> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: QB1PPF4C719E46A:EE_|YT2PR01MB8422:EE_ x-ms-office365-filtering-correlation-id: 240c3ff2-81a9-4d24-fcee-08dd7785c501 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0;ARA:13230040|376014|366016|1800799024|38070700018|13003099007|8096899003|7053199007; x-microsoft-antispam-message-info: =?us-ascii?Q?kvLsAKCN9raip0Johxw53FI7HnKkLOep1jJyBTzIEchng/U2Wqu8pV8u0B8p?= =?us-ascii?Q?78LcFU63V8sgwPgsgzKmxaIqV81WXDZSDdvp8cfUyBPSXuAr0DaOC9BFS/vu?= =?us-ascii?Q?lOh0Axp43lAp3HtVCm7Kwoe6wQ50A99xT/c6f8Fv2iHt3CUwan3lzMsmd730?= =?us-ascii?Q?bIhQMVSj6RcBXrzVj52svPTzusd++Pd2IscZXeWJxTG/pUk2IrOFqSrXxiAK?= =?us-ascii?Q?keswKIzd8N1+B7SQ40VJTSlHIqa/YohkkLiHxb1igxZBPSCPxXNw3uXGr+7h?= =?us-ascii?Q?wJQonROH2fKEPaBdP1QZW17RbWowlBqOF+3Zx6+BpFgJdAOnoZ1gLsCcOiFe?= =?us-ascii?Q?ChVl8coiyYYvk3KbP6GAv3wqLSMrXoZho6h3Srn2366OHvT003nDByeYKqSm?= =?us-ascii?Q?kL8FVd8qxLv+2NEBJLsn+oH+fPbrqzPM4AJ5ZiL+XHNi6oMyvFhFUzogMa6h?= =?us-ascii?Q?WC7hnkcwslX/h6gW+0DKCy/3a/aQvEtM/WRSN3mSK/jyXTUMGcFQ4e8naJGu?= =?us-ascii?Q?3kxXz2MT4tWiOv2rL9cSq61ELxhdc6AULvRH4ostkPlOzBCrPHyIgv+vNYMZ?= =?us-ascii?Q?sM16/HKkfJRDrFZm8+1v/LiQVbI2+mqviYF2o2FVj2K0y+3Q0RwqyfKIsbPj?= =?us-ascii?Q?0kOxC2Yggn0KhhUGYeGVrAbYFLt6VWwq3J/JBMmjA+75ynkJWj0koMvhoIwR?= =?us-ascii?Q?KJyL4MZExBmwFMid/5qh27Yb8DOquVB/Rmr9KX4vFX2TCnW9rxWEQZWdZnL8?= =?us-ascii?Q?hkzmxElJDGQ//4JA9gYkayahBoNIjYwHhUVqVdkCcIh3bImcGPe8s7LjPmKX?= =?us-ascii?Q?gvHObuZxkYjDUQzbqcEUKCDLoQSwOs4X0RYcGaWOEHdzpJYHuGFBdE2nJReB?= =?us-ascii?Q?RojkZkLe8m0wggZD8ipZf4Yw0MuDxWdwf3epsRJll3YeNFNb6OB/KvvREacu?= =?us-ascii?Q?Agqlab9gJApgVWZv6Vr2YCUV8Y1Tp4vDsz/zbJ/QAabZDWmnWSqmo7oAcCeb?= =?us-ascii?Q?4tjhAO/uu1ZboXsqknlAGGkpKfhcSSctPRj2E223tmCGZkSPHsIGifXvtwHv?= =?us-ascii?Q?L89+Ikvp79/OH/5yt8ELT/Ss56WUFPyFpzXt7KtBXFxdDphJCBghStzfz0Dg?= =?us-ascii?Q?L7TMzAsc7oxgWvs9uDe1egOjcEsMLNx25vWF3X4gkx3jPENQLHx2u1HVH0ne?= =?us-ascii?Q?s4ESO5c0olHhjLdEWpyNFLLRVWUh45HJ7YKVCpfwCfhePtyyabhdWvXRJWif?= =?us-ascii?Q?QTdEG76YEUG8g748gxlWChH1vdV0mh+T5/ndGMVT5LBLsmat29XFlr1GMalb?= =?us-ascii?Q?XRqYrMR1iLDjGEJQ4gU1ReXvfo3l+YYC1Ygm4EOcWXxoXCi0B2oPrIE9MhUt?= =?us-ascii?Q?X5rVW5vslnh74CAzyMtUm8tJsbp+DWkna4woU+eDdz/vIJyfbR9MUCxtykaV?= =?us-ascii?Q?1wURtQEGGz8uiUkibSS4zww/4SZ5DKNNb7r6E9xdf7zZSGqoXwK5vx80jCDG?= =?us-ascii?Q?IwSWcwkx401RKtU=3D?= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(366016)(1800799024)(38070700018)(13003099007)(8096899003)(7053199007);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?t/3BQ7Te4hkQPiIiCWfoHGk1YZwrfW70N3Y4uWvvKPKhnHDAbcfClc03HdRu?= =?us-ascii?Q?NXiRfJb9DlqOySKpQZ+X+MDbicUBNlRJ5omGaiKoIolAxfTeP7lIx+9jEVFI?= =?us-ascii?Q?KabhU31MpgxGYu3cya0Ht2/syQpcVIrMEG5sf97sClyYNyddA7VowfdAeZ14?= =?us-ascii?Q?/25yWJEqPHdY6fvwABwIx2b2cUecwlrQs1QABcf1CZXTHLnjv4FBaCtXLPNX?= =?us-ascii?Q?YIpX2en4zp2a0VzJawVMFdEvfwiBuuBR0zcW0Mj0wx3HetT/EKhTM/ZYSYqx?= =?us-ascii?Q?SvpsbrfxuHS0ONsjUeqs0WmX0wp6SwFPmxI1k0okUp0FfIBBDy2rSKy8T6Y9?= =?us-ascii?Q?jzJGeWTAUGTbJqLX5ju7DbU+jDhGr7BPSVAmGdMUVR9487yaangUa3F+2ihl?= =?us-ascii?Q?KvFwLw06iXlb1HpKx1JsNJ1YpePUJqz6dLRTCX7Akzw/Bn0zPbuVmazZNLiu?= =?us-ascii?Q?/25XyeCd94dbYXSl5ONtGu9YgN+k4jgCTDlTanYMxIH38e7EvShOVP7gV0D/?= =?us-ascii?Q?zqrJTCIRIvo4HVsE3Qgvpl/prB8v6oqnAlSoFR0x23nT1t6M3U0Jlbj3IRPg?= =?us-ascii?Q?+eGENJgTWWKf5W1wL6t1s2iYfT3nIO1QWbI27QiP3s2kQBBisRt6/Xr8jRhv?= =?us-ascii?Q?8UTv6LerJ+J3ahTrnwqqThdO1J8nD3uQuhJG+YrlTk4VujbH297Ulu29U4CO?= =?us-ascii?Q?HcyPfQaRt1xiiJOv3ZOOrQMJcIfo9+DwQ9ZwlN1PB5xaWtFZPqyXkT0cYP8D?= =?us-ascii?Q?COQ2tPKpWbEYqupxSvz5Ty228WVADkzW9WaCLY2fqtP9TfmZtD3j2DD8zHUj?= =?us-ascii?Q?v28qptTMIToz/8mg3dwyJJbUoWvJHtLHw8HOPNhGUje928TB03kpwHLrvwpk?= =?us-ascii?Q?8T5f8V1sR30wXcVjfCIEfrr1haYgQl/uEC0PAtaqdsDxb5MO2CtImz1gHvAA?= =?us-ascii?Q?n972VZ/wmzcwbzQIrbGADexQgcLpDcVnB+0fM6Wz0D8UwP8X3OP2gJ7x7IAD?= =?us-ascii?Q?zsn6owMf7sxOKbXoOkWN+bp5OufvS/z9/la6j0XNK22Q+p0XI+X1btYttLbT?= =?us-ascii?Q?APjTcvVUs0cgL5aVrM0pCuVz+ZuQ6simj1PjdXLoRp77lWK4rFb9cDBOYSDP?= =?us-ascii?Q?JVyPGIGt6iO49PrlhkAykeNap6PhchI/U4Ge1/Fjl4inITL9X4UfrQPYBLYE?= =?us-ascii?Q?1LOjuZkUkefDOwayY6rAdrS4jdfAzCQHTQ+l1qaKL5q6kWD7k3rcb9SwiYym?= =?us-ascii?Q?8wmy/GXB2WxAWNXMJsCcJ5DhM//V/Hu5f+I4G9KNyQ7+CTiExEQcu53/dt7Q?= =?us-ascii?Q?YIzVvFdUQc/vpy2R6GuYS3GClXsll4K+skRgWO+Bh/M6B3OHs9g16UY4C5Jz?= =?us-ascii?Q?SMQ782brYBRKcOHTGXu3OFonh+xWfCufHDLNsYC/QhfZz8Iq1TTPb4gYV3cW?= =?us-ascii?Q?XSakJLeARujVmDZt5Ln8jSzi6tHELRWOc2GIV12AF0uQ9fOXRJcxeaSHciLX?= =?us-ascii?Q?un7B52/D2pPyFyK6zKNcwoi91/93X4F2hRNzV8yMlOqWMn127NJjv9Zd/oXh?= =?us-ascii?Q?Ho5VA6KbFuE6Om2YKtnAlKKfyR6yH/A61MWy9BVurpahMhMhpfT1pnFzuc6i?= =?us-ascii?Q?tA4m0+lda6L5mGJZqee2Up0=3D?= Content-Type: multipart/alternative; boundary="_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_" List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 X-OriginatorOrg: willowglensystems.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PPF4C719E46A.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 240c3ff2-81a9-4d24-fcee-08dd7785c501 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2025 16:44:17.5653 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c7bca0fa-9d0c-460d-8770-da688c84194e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U8cw9U3udcujxv/gcFMkttEAbQsEcn0XUMq592HRIc8gtlwjq+TCFmpunoQIa7rbgrIEi4uDZG1TCA8jxpBQfYnC07YLKydLqHVtYUaa8wwk007Cw/DR+VcvcQu6DA6G X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT2PR01MB8422 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:8075, ipnet:40.104.0.0/14, country:US] X-Rspamd-Queue-Id: 4ZXpgv5LQ5z3vCD X-Spamd-Bar: ---- --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "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) defi= ned depending on the inclusion of INET v4 or 6. I just cloned them as ... _UNHOOKED_ ..., and made them the NOT of the HOOK= ED_ 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_fastfw= d) 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 tha= n with my changes lol. ________________________________ From: Zhenlei Huang Sent: April 9, 2025 1:48 AM To: Robert Austen Cc: freebsd-current@freebsd.org ; freebsd-net@= freebsd.org ; Kristof Provost ; Cy= Schubert Subject: Re: pfil_default_to_drop You don't often get email from zlei@freebsd.org. Learn why this is importan= t On Apr 9, 2025, at 1:01 AM, Robert Austen > wrote: I respectfully disagree. PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= o enable itself, ie. to apply any hooks. if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= o 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 ( DIOCSTAR= T ) 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, t= he 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 l= ikewise 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` a= nd `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=3D5f17ebf94db5ebbc7fdcff60= e598498df6f9e2bd . as I said, this is because there's no mechanism within PFIL to drop by defa= ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= O_DROP, because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= FAULT_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 ha= ve any tunables to control that. CC @Cy who is more familiar with ipf(4). thanks! ________________________________ From: Zhenlei Huang > Sent: April 7, 2025 7:55 PM To: Robert Austen > Cc: freebsd-current@freebsd.org >; freebsd-net@fre= ebsd.org >; Kristof Provost > Subject: Re: pfil_default_to_drop You don't often get email from zlei@freebsd.org. L= earn why this is important On Apr 8, 2025, at 6:36 AM, Robert Austen > wrote: ________________________________ From: Robert Austen > Sent: April 7, 2025 4:33 PM To: freebsd-current@freebsd.org >; freebsd-net@fre= ebsd.org > Subject: Fw: pfil_default_to_drop ________________________________ From: Robert Austen Sent: April 7, 2025 4:21 PM To: 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 Op= en/FreeBSD + PF seems to be a common starting point. I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd 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.k= o ( via the loader(8), /boot/loader.conf ) ? With 13.5, or upcoming 14.3 ( you can also experiment latest stable/14 ), y= ou 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=3Dc531c1d1462c45f7ce5de4f9= 913226801f3073bd . 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 t= he level of PFIL, the kernel packet filtering code: If no filter is loaded, i.e. if the heads are unhooked, then PFIL sends everythin= g 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 cho= sen 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 ho= oks 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 o= f 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 fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64, but I suspect the kernel code in the networking core doesn't change much fr= om 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 --_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
"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 H= OOKED_ 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_fastfw= d) 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 tha= n with my changes lol.


From: Zhenlei Huang <zle= i@FreeBSD.org>
Sent: April 9, 2025 1:48 AM
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 &= lt;kp@FreeBSD.org>; Cy Schubert <cy@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 9, 2025, at 1:01 AM, Robert Austen <robert.austen@willowgl= ensystems.com> wrote:

I respectfully disagree.

PF_DEFAULT_TO_DROP has no effect if pfctl does not perform its ioctl call t= o enable itself, ie. to apply any hooks.
if pfctl fails, then the hooks are left unhooked, and EVERYTHING defaults t= o 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 (&nbs= p;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, t= he 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 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 o= r accept.


as I said, this is because there's no mechanism within PFIL to drop by defa= ult, which is why I proposed (and am using on my system) the PFIL_DEFAULT_T= O_DROP,
because it handles ALL of the 'no filter installed (yet)' cases. if PFIL_DE= FAULT_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 n= ot have any tunables to control that. CC @Cy who is more familiar with ipf(= 4).


thanks!
From: Zhe= nlei Huang <zlei@FreeBSD.= org>
Sent: April 7, 2025 7:55 PM
To: R= obert Austen <robert.austen@willowglensystems.com>
Cc: <= a href=3D"mailto:freebsd-current@freebsd.org" class=3D"">freebsd-current@fr= eebsd.org <freebsd-current@freebs= d.org>; freebsd-net@freebsd.org<= span class=3D"x_Apple-converted-space"> <freebsd-net@freebsd.org>; Kristof Provost <kp@FreeBS= D.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@willowgl= ensystems.com> wrote:




<= b class=3D"">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 Op= en/FreeBSD + PF seems to be a common starting point.

I've noticed a number of people asking questions about PF_DEFAULT_TO_DROP a= nd 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_D= ROP, 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 tu= nable net.pf.default_to_drop to 1, and preload pf.ko.
See also https://cgit.f= reebsd.org/src/commit/?id=3Dc531c1d1462c45f7ce5de4f9913226801f3073bd&nb= sp;.


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 t= he level of PFIL, the kernel packet filtering code: If no
filter is loaded, i.e. if the heads are unhooked, then PFIL sends everything&n= bsp;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 cho= sen 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 ho= oks 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 o= f 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 fol= der. The code was written against FreeBSD-14.1-RELEASE-amd64,
but I suspect the kernel code in the networking core doesn't change much fr= om 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




<Fr= eeBSD-14.1-RELEASE-amd64-pfil_default_to_drop.patch.zip>



--_000_QB1PPF4C719E46AFADEAB65EB14D2627AABEFB42QB1PPF4C719E46A_--