[HN Gopher] OpenBSD PF versus FreeBSD PF
       ___________________________________________________________________
        
       OpenBSD PF versus FreeBSD PF
        
       Author : zdw
       Score  : 131 points
       Date   : 2023-09-27 18:09 UTC (4 hours ago)
        
 (HTM) web link (mwl.io)
 (TXT) w3m dump (mwl.io)
        
       | Anya200 wrote:
       | [flagged]
        
       | tiffanyh wrote:
       | Don't forget DragonflyBSD version of PF.
       | 
       | They look an old version of OpenBSD PF and updated it to be
       | multithreaded.
       | 
       | I could be mistaken, but I believe both FreeBSD PF & OpenBSD PF
       | are still single threaded.
       | 
       | https://man.dragonflybsd.org/?command=pf&section=4
        
         | darkhelmet wrote:
         | DragonFly and FreeBSD have radically different ideas on how
         | multithreading should work. (Understatement of the century
         | right there!)
         | 
         | FWIW the threading in the network stack is one of the original
         | major divergences between Open/FreeBSD PF. The way FreeBSD's PF
         | works is within the context of FreeBSD's threaded network
         | stack. FreeBSD PF is not "single threaded" in the way it used
         | to mean.
         | 
         | I would _really_ like to have the modern PF syntax /structure
         | from OpenBSD in FreeBSD though. The unified rdr/nat/pass/block
         | mechanism in OpenBSD is so much cleaner and nicer to work with.
        
           | cperciva wrote:
           | _DragonFly and FreeBSD have radically different ideas on how
           | multithreading should work. (Understatement of the century
           | right there!)_
           | 
           | To elaborate for people who don't know the history:
           | Disagreement about how multithreading should work are why
           | Matt got booted from the FreeBSD project and started
           | DragonFly.
        
             | darkhelmet wrote:
             | It's not that simple. Disagreements are one thing, but the
             | real reason was the conflict and drama that happened when
             | things didn't go his way. The threading approach just
             | happened to be a really good trigger for those conflicts.
             | 
             | Conflicting personalities makes resolving technical
             | disagreements so much harder.
        
               | cperciva wrote:
               | I was being euphemistic. It was a "doesn't play well with
               | others" issue, but it came to the fore with SMP.
        
         | dmm wrote:
         | FreeBSD pf has been multithreaded for a long time. The FreeBSD
         | 11 pf(4) man page from 2013 specifically says so[1].
         | 
         | [1]
         | https://man.freebsd.org/cgi/man.cgi?query=pf&apropos=0&sekti...
        
           | Lammy wrote:
           | "SMP" might be a more useful search term. You're correct on
           | the timeframe -- merged into HEAD in 2012
           | https://lists.freebsd.org/pipermail/freebsd-
           | pf/2012-Septembe...
           | 
           | I'm not an OpenBSD user but it sounds like this changed
           | recently in OpenBSD-land as well, because the "Will multiple
           | processors help?" FAQ entry disappeared some time between
           | January and March 2023: https://web.archive.org/web/202301121
           | 70731/https://www.openb...
        
             | gigatexal wrote:
             | I didn't know this but it makes sense. Either way for most
             | of the use cases (homelabs on residential internet speeds)
             | either FBSD or OpenBSD's PF will perform just swimmingly.
        
         | postmodest wrote:
         | The only advantage I can see to MT PF would be multiple NICs.
         | And even then they have to be really beefy NICs
        
           | smashed wrote:
           | From what I understand, modern NICs have multiple Rx/tx
           | queues and thus the work of sending and receiving can be
           | assigned to different kernel threads.
           | 
           | The number of queues will vary according to the specific NIC
           | chip.
        
       | drewg123 wrote:
       | And if you're using FreeBSD with a fast NIC, look into the
       | pfilctl command and use a "head" input hook into your NIC
       | driver's ethernet input handling routine. Doing this allows the
       | firewall input checks to happen early, before the packet has been
       | received into the network stack, while its still in DMA-mapped,
       | driver-owned buffers. If the firewall decides a packet is to be
       | dropped, the NIC can recycle the buffer with minimal overhead
       | (skips DMA-unmap, buffer free, ethernet input into the IP stack,
       | and the replacement buffer alloc, DMA map).
       | 
       | This allows for _very_ fast dropping of DOS flood attacks. I 've
       | tested this using ipfw up to screening and dropping several 10s
       | of millions of packets on 2014 era Xeons with minimal impact to
       | traffic serving. I wrote a paper about this for a conf. that was
       | cancelled due to COVID. I really need to re-submit it someplace.
       | 
       | This works for Mellanox, Chelsio, and NICs that use iflib (ix,
       | ixl, igb, bnxt, and more that I'm forgetting).
        
         | bravetraveler wrote:
         | This is awesome to see [as a mostly-Linux person] - people have
         | managed to impress the sentiment on me that the BSDs are well-
         | suited for networking.
         | 
         | I never quite 'got it' - this helps. Are you aware of similar
         | tweaks in Linux land, by chance?
         | 
         | I consider myself reasonably well-experienced as a systems
         | administrator... but can't quite recall stumbling across
         | anything quite like this.
        
           | ADSSDA wrote:
           | IMO Linux is significantly better than the *BSDs at this
           | particular use case.
           | 
           | Check out https://blog.cloudflare.com/l4drop-xdp-ebpf-based-
           | ddos-mitig...
           | 
           | and:
           | 
           | https://github.com/xdp-project/xdp-tools
        
             | diogenes4 wrote:
             | Linux certainly offers much better functionality overall
             | but the tooling for this is a poorly documented and
             | inconsistent nightmare.
        
               | ilyt wrote:
               | There is definite lack of a declarative tool that glues
               | it all.
               | 
               | Typical hardware switches and routers just have one
               | (sometimes expanded by includes/macros but still) config
               | syntax to control every part of networking stack.
               | 
               | So you can configure interface and set its vlans all in
               | one place instead of creating a dozen of ethX.Y devices
               | then crerating a bunch of brY bridges and then attaching
               | the interfaces to them
               | 
               | In linux instead you'd be using iproute2 set of tools to
               | configure interfaces and static routing, iptables for IP
               | ACLs, ebtables for ethernet ACLs (or now nftables I
               | guess), without any tool to apply/revert changes at once
               | 
               | Many tried doing that but IMO haven't seen anything good.
               | 
               | Many also try to "simplify" iptables and all it ends up
               | is me being annoyed coz I know which iptables commands I
               | need to run but I need to translate it back into "higher"
               | level config syntax. One exception being ferm (
               | http://ferm.foo-projects.org/ ), because it keeps
               | iptables-like keywords just expands on that, but it is
               | iptables only and kinda superseded by nftables syntax
               | anyway.
        
               | epcoa wrote:
               | iptables/ebtables is deprecated even in RHEL. While
               | people are free to continue not to transition to nftables
               | complaining about problems with iptables after a decade
               | of its replacement is a bit silly.
        
               | chasil wrote:
               | I would trade firewalld for pf in an instant.
        
             | gigatexal wrote:
             | But don't have to cobble together a bunch of arcane
             | iptables commands and then combine bpf and other userland
             | tools ... when one can just use the clean syntax of PF
             | especially for home use that's a clear win.
        
               | ADSSDA wrote:
               | I've used both extensively and I find eBPF+iptables (and
               | sometimes nft) significantly more flexible and easier to
               | use in the real world (not just simple examples) than PF.
               | _shrug_
        
               | gigatexal wrote:
               | Do you have a sample or blogpost of how your setup looks?
               | I'm keen to see how folks are using eBPF in the personal
               | firewall space
        
               | systems_glitch wrote:
               | Not having to manage two rulesets -- one for IPv4 and one
               | for IPv6 -- is pretty well a killer feature in my mind.
        
               | nolist_policy wrote:
               | nftables is now almost 10 years old! It's time to forget
               | the bad experiences with iptables.
        
               | throw0101a wrote:
               | > _But don't have to cobble together a bunch of arcane
               | iptables commands_
               | 
               | If you did manage to figure out the _iptables_ commands
               | you now have to change them over to _nftables_. :)
        
               | carlhjerpe wrote:
               | No, iptables is a perfectly functional nftables frontend
        
           | epcoa wrote:
           | https://en.wikipedia.org/wiki/Express_Data_Path
        
             | bravetraveler wrote:
             | Thank you, I've heard of {e,}BPF but not so much
             | applications - thank you again!
             | 
             | Makes sense why I haven't seen it, came out around the time
             | I joined $CurrentEmployer, and we're stuck a couple decades
             | behind.
        
         | datadeft wrote:
         | This sounds nice for a specific case when you are not dealing
         | with bandwidth based DOS.
        
         | gigatexal wrote:
         | I had no idea! This is really cool. Have you by chance a blog
         | about it?
        
         | digitalsushi wrote:
         | I'm picturing that scene a few episodes into the soul art anime
         | - I barely remember it but the main character was so
         | overpowered, he was standing there absorbing a full barrage
         | from a much lower ranked opponent flooding him with punches and
         | kicks; the main character's health regenerated so quickly that
         | the attack didn't have effects.
         | 
         | In 2014 I was working on a hardware appliance for a company
         | that has something to do with packet capture, and I found an
         | intel driver that implemented a ring buffer on a 1 gigabit
         | Ethernet adapter that allowed me to capture line rate without
         | dropping a single packet over the course of hours; prior to
         | this the adapter was barely able to capture 90% of the packets.
         | I remember marveling at the design that must have gone into it,
         | and here too to your description of this performance
         | improvement.
         | 
         | I miss that stuff. Thanks for sharing,
        
         | brynet wrote:
         | > This allows for very fast dropping of DOS flood attacks.
         | 
         | OpenBSD has something very close to that w/ bpf(4) BIOCGFILDROP
         | filter "drop".
         | 
         | https://man.openbsd.org/bpf#BIOCGFILDROP
         | 
         | https://man.openbsd.org/tcpdump#B
         | 
         | https://marc.info/?l=openbsd-tech&m=155228135415650&w=2
        
           | tedunangst wrote:
           | I think that's pretty different. It's less processing, but
           | still copies packet off nic.
        
           | [deleted]
        
         | jpk wrote:
         | Would love to watch that talk (so please re-submit it
         | somewhere!), but in lieu of that, is the paper available
         | anywhere?
        
       | wkat4242 wrote:
       | And then there's macOS pf too. Also different again!
        
         | cyberpunk wrote:
         | I'm sure i read on a comment here recently that the latest
         | macos is using a recent openbsd pf? As quite a heavy user of
         | freebsd pf, I wonder if anyone knows more details on that?
        
           | nvy wrote:
           | On my mbp, the man page for `pfctl` contains the following:
           | 
           | >HISTORY
           | 
           | > The pfctl program and the packet filter mechanism first
           | appeared in OpenBSD 3.0.
        
             | yakubin wrote:
             | The same is in the current manpage on OpenBSD:
             | <https://man.openbsd.org/pfctl>. The next line is more
             | telling though:
             | 
             | > July 1, 2007
             | 
             | Although I'm running Monterey, so maybe it's updated in
             | more recent versions of MacOS.
        
               | nvy wrote:
               | Mine doesn't have a date at the bottom, just a macOS
               | version number.
        
               | nvy wrote:
               | edit: never mind, it does
        
               | wkat4242 wrote:
               | Still 2007 here in macOS Sonoma 14.0
               | 
               | I'm just super surprised it's there at all considering no
               | rules are defined by the OS, and nobody uses it anymore
               | because all the firewall vendors moved over to system
               | extensions.
        
           | toast0 wrote:
           | I haven't looked in a while, but an update would be nice.
           | When I was looking at it in the last couple years, many
           | things in the networking stack were unchanged since the late
           | 90s/early 2000s, so macos didn't have syn flood protection
           | built in, and while the macos pf had synflood stuff, it only
           | works if the macos host is strictly a firewall, using the syn
           | protection for traffic where macos is an endpoint results in
           | no connectivity.
           | 
           | If they pulled in a more recent pf from either OpenBSD or
           | more current FreeBSD would be welcome. (And you know, a
           | recent tcp stack would be nice too; although they've added in
           | things like MPTCP that they'd need to port forward by 20+
           | years)
        
         | chasil wrote:
         | Solaris also uses pf as the native firewall, iirc.
        
       | josteink wrote:
       | > And the PF syntax is the most approachable in all of open
       | source Unix.
       | 
       | As someone not deeply into the BSDs and who has never tried pf, I
       | would love to see this claim illustrated with a few examples.
       | 
       | Are there any "definitive" or authoritative beginner guides for
       | those merely curious, but without a production system to test on?
        
         | i_am_a_peasant wrote:
         | I'd go for the handbook in that case:
         | 
         | https://docs.freebsd.org/en/books/handbook/firewalls/#firewa...
        
         | nesarkvechnep wrote:
         | Get yourself "The Book of PF" and get to work.
        
         | fragmede wrote:
         | Explore in the direction you want to go:
         | 
         | https://chat.openai.com/share/e1e2a207-5fb4-4f12-9f3c-7850ff...
        
         | tedunangst wrote:
         | Find your favorite topic in
         | https://www.openbsd.org/faq/pf/index.html and compare to how
         | you'd do it in your favorite firewall.
        
         | voytec wrote:
         | > And the PF syntax is the most approachable in all of open
         | source Unix.
         | 
         | I actually find ipfw(8) [0] syntax more human-friendly.
         | 
         | [0]
         | https://man.freebsd.org/cgi/man.cgi?query=ipfw&sektion=8&for...
        
           | stock_toaster wrote:
           | I wish dragonflyBSD's ipfw3 would get ported to freeBSD.
        
       | jayp1418 wrote:
       | Also don't forget NetBSD 's npf
        
         | idatum wrote:
         | I wanted to use npf but I couldn't figure out how to implement
         | NAT64. The syntax looked nice though.
        
           | systems_glitch wrote:
           | Juuuust different enough to be aggravating :P
           | 
           | Check the /etc/examples stuff for the best docs on `npf`.
           | Most of what I found online was outdated or just plain wrong.
        
       | tedunangst wrote:
       | For a bit of context regarding some of the "unfixed" issues in
       | FreeBSD, some of it comes down to different security contexts. In
       | openbsd, pf is pretty much root only, and root -> kernel
       | escalation isn't a big deal. There's a bug, it gets fixed, but no
       | hoopla. Easy to miss if you're not paying close attention. Maybe
       | fixed incidentally as part of a refactor.
       | 
       | But FreeBSD also has jails/vnet, which makes root -> kernel
       | escalation a lot more spicy. Eventually the bug gets found, some
       | years later, although not really the result of negligence.
        
       ___________________________________________________________________
       (page generated 2023-09-27 23:00 UTC)