Future of pf / firewall in FreeBSD ? - does it have one ?
list_freebsd at bluerosetech.com
Thu Jul 31 07:41:07 UTC 2014
On 7/29/2014 3:18 AM, Gleb Smirnoff wrote:
> On Sat, Jul 19, 2014 at 09:36:06PM -0700, Darren Pilgrim wrote:
> D> Never mistake silence for consent.
> D> The vast majority of people don't know pf is outdated and broken on
> D> FreeBSD because they don't know what they're missing and likely aren't
> D> using IPv6 yet. The moment you turn on IPv6 and restart a validating
> D> unbound, you run full-speed into pf's broken behaviour. Make an
> D> EDNS0-enabled query for a signed zone and you'll get a fragmented UDP
> D> packet that will never make it through unless you tell pf to allow all
> D> fragments unconditionally. They'll simply think something is wrong with
> D> unbound, turn off EDNS0 and/or validation, hurt peformance and/or
> D> security in the process, and never realize their firewall is doing
> D> literally the worst possible thing it could do.
> D> All because over half a decade ago some folks got all butthurt over a
> D> config file format change.
> Do I understand you right, that you propose a tens thousands lines of
> untrivial code bulk update in order to fix a particular bug, that can be
> nailed down separately?
No. I believe pf should be removed from FreeBSD and efforts refocused
on keeping ipfw up to date and feature complete. It makes more sense to
look at what pf, ipf, nbtables, etc. are all doing as a source of ideas
for what we can do with ipfw. A decade ago, there was justification for
adding pf: at the time, ipfw lacked some major features.
Ipfw has since caught up. I see no remaining value in having more than
one packet filter in the base. Ipfw is more mature and less broken, so
we should keep it and ditch the rest in the name of survival efficiency.
> Do you also say that breaking configuration
> files for a large number of people is okay if the update is expected
> to fix a bug unrelated to configuration?
Yes. Loss of configuration file backward compatibility is a fact of
progress. Here are some examples of places where FreeBSD broke backward
compatibility of a configuration file:
- rc.conf (with every major version change)
- make.conf vs. src.conf
- the ports collection
- pkg vs. pkgng
- pkgng changes within pkgng 1.x
On top of that, we also have whole chunks of the OS where compatibility
was broken (e.g., the toolchain, switch to unbound, etc.).
> For me sounds like hunting a sparrow with a cannon.
The whole thing, to me, was an example of lobbyist politics: a vocal
minority had the resources and access to stop progress. Now we are all
suffering for their ignorance and arrogance.
If anything, we should rename pf to tppf (short for "Tea Party Packet
More information about the freebsd-questions