Slashdot Mirror

← Back to Stories (view on slashdot.org)

New PF on FreeBSD snapshot available

Posted by michael on from the latest-and-greatest dept.

Dan writes "Pyun YongHyeon and Max Laier announce a new release of PF for FreeBSD, which is available for download. Since the first release of PF at the end of March 2003, PF has undergone several major updates such as -current and ALTQ support. They have also removed bugs in IPv6, module handling and table support code and believe the current version 0.61 is very close to production use."

13 of 58 comments (clear)

  1. Re:PF? by TilJ · · Score: 3, Informative

    PF is short for 'packet filter', and it's the native firewall code for OpenBSD. Here's the man page for the config file.

    PF is fairly new compared to IPFW and IPFilter, but it has reapidly been gaining advanced features and capabilities. Porting it to other operating systems is a good thing IMO - the more competition in this field, the better ;-)

    --
    "The purpose of argument is to change the nature of truth." -- Bene Gesserit Precept
  2. Re:Now we have to relearn FreeBSD networking?? by phoenix_rizzen · · Score: 4, Informative

    Actually, this is nothing like in Linux. In Linux-land, each new kernel brought out a brand-new, almost compeltely incompatible packet filter. ipfwadm, ipchains, iptables. The syntax changed. The features changed. There was no way to use the old filter. There were wrapper scripts to try and simulate this, but they are crud. Heck, the packet filters themselves are crud.

    In FreeBSD, there's IPFW *or* IPFilter *or* Packet Filter. IPFW has been around a long time, and the syntax has changed very little. New features have been added, though, but all the old features still work. Same with IPF. Nobody is forced to switch from IPFW to IPF or PF. They can continue to use IPFW.

    It's much nicer to be able to continue to use the same packet filter across minor *and* major versions of an OS. It's also nice to have a choice of two or three packet filters.

    I'll definitely stick to BSD for packet filtering. Linux is nothing more than a toy.

  3. For those not keeping score... by drdink · · Score: 3, Informative
    PF is the Packet Filter used in the latest releases of OpenBSD. OpenBSD developed pf after a licensing dispute with Darren Reed basically resulted in him telling OpenBSD to go to hell.

    FreeBSD, up to now, has had two different firewalling methods. First off, there is the natively developed ipfw tool, which recently got a renovation and is now ipfw2 in -CURRENT. The alternative to ipfw is Darren Reed's ipfilter, also known as just ipf. Both ipfw and ipfilter share similar capabilities, and it is generally user preference as to which one is used in FreeBSD.

    Now, it seems somebody has made the effort to port yet another firewalling mechanism to FreeBSD, this time pf. The features it claims to have over ipfw are:

    • built-in variable expansion
    • built-in NAT and preventing NAT detection
    • table (a kind of very large blocks of address) support
    • packet normalization
    • state modulation
    • powerful state tracking
    • automatic rule optimization
    • queueing with ALTQ
    • load balancing with multiple routes

    Presumably, some of these are rather desirable features. However, it is beyond me why FreeBSD needs yet another way to do firewalling when the interfaces and systems we have now already work well. It is my opinion that instead of porting something proprietary to OpenBSD like pf, time should have been spent either patching these features into ipfilter or ipfw to add functionality to an already accepted and loved firewalling mechanism. There is no reason FreeBSD needs to dig a deeper firewalling grave for itself like OpenBSD has done.

    --
    Beware, Nugget is watching... See?
    1. Re:For those not keeping score... by hununu · · Score: 3, Interesting

      In order to get pf's nice features into ipfilter, you would have brain-wash Darren Reed I guess. :-)
      pf has a lot of interesting things like alt-q integration (yes, not implemented in -current yet but there are working patches at altq's site), tables, etc (you mentioned them).

      And yes, more is better. A lot of people (including me) use on some servers ipfw and ipfilter/ipnat at the same time because it's useful and you can take the best of each "world". pf introduction will give users even more options, nothing more, nothing less.

    2. Re:For those not keeping score... by Huge+Pi+Removal · · Score: 3, Informative

      If you read the man page for ipfw and compare & contrast with the man page for pf, you can immediately see just how much better pf is.

      ipfw is basically a basic packet filter with a few things bodged on top of it (variable expansion, keeping state, etc) (OK, that's a bit unfair, but it's what it *feels* like to use). pf is a built-from-the-ground-up total firewall solution, with a hell of a lot of flexibility, and also several functions which will do in one line what it takes ipfw rather longer to do (e.g. anti-spoofing). Plus the simple command "scrub in all" on your border router immediately renders most TCP-fragmentation attacks benign.

      Essentially, if you want a router with a bit of filtering, ipfw will do you. If you want a serious firewall, go for pf. However, if you want a serious firewall, you should already be going with OpenBSD anyway :)

      --
      - Oliver

      The right to bear arms is only slightly less stupid than the right to arm bears...
    3. Re:For those not keeping score... by R.Caley · · Score: 2, Interesting
      However, if you want a serious firewall, you should already be going with OpenBSD anyway :)

      Actually, Theo's `licencing restrictions are for the lower orders not me' squabble with Darren Reed happened just when I was getting ready to put ina firewall. OBSD was the planned system, but theere is no way I was going to run a brand new piece of software in such a role, and I'm not sure I think PF is long enough in the tooth to be comfortable yet. So my firewall and the two I am setting up for work are FBSD/ipfw.

      --
      _O_
      .|<       The named which can be named is not the true named
    4. Re:For those not keeping score... by drdink · · Score: 2, Insightful
      ipfw is basically a basic packet filter with a few things bodged on top of it (variable expansion, keeping state, etc) ( OK, that's a bit unfair, but it's what it *feels* like to use).
      Okay, so you admit your own explanation is biased and wrong. That basically invalidates that "point" you made. Have you looked at the rework of ipfw which is in FreeBSD 5.0-CURRENT and known as ipfw2?

      pf is a built-from-the-ground-up total firewall solution
      ...which means it has some time before it is truely accepted by everyone. Both ipfilter and ipfw have been around for a long time and alraedy proven themselves to work well. In my opinion, pf still has a while to go before it proves itself to the extreme that the others have.

      Essentially, if you want a router with a bit of filtering, ipfw will do you. If you want a serious firewall, go for pf. However, if you want a serious firewall, you should already be going with OpenBSD anyway
      I don't choose my tool by the ease of configuration alone. I also choose my tool by its proven stability, flexibility, and how tightly integrated it is with the other things I am using. Since ipfw fits in all three of these categories, that is my tool. I also prefer FreeBSD over OpenBSD, though the reasons for that aren't really relevant to this conversation. I'll just summarize it by saying that I believe FreeBSD has much better leadership and downloadable ISOs in the same layout as the purchasable ISOs.

      It seems like you totally missed my point I made in my comment above. My point was not "we should go with whichever is better." In fact, it was very different from that. My point was "we should merge the good from others into the existing good we have already." I don't want to switch tools, configuration file formats, and APIs. That was the point I was making. These things should not change. Switching or adding pf to my system will do all these things, along with increasing the size of my source tree just to give me a duplicate tool.

      And in closing, a real network administrator wouldn't use OpenBSD for a firewall. They would use a hardware device designed from the ground up for the specific job of being a firewall. And no, this is not an argument that can be extended to pf vs. ipfw, since ipfw was also designed to be a firewalling tool, has been around longer, does a decent job already (especially with ipfw2), and so forth.

      --
      Beware, Nugget is watching... See?
    5. Re:For those not keeping score... by Huge+Pi+Removal · · Score: 2, Insightful

      I think the sizes of the patches for AltQ stuff for pf and ipfw respectively show how well-written and flexible pf is. I use FreeBSD a lot, and have used ipfw (and ipfw2, although probably not the latest build) extensively. Writing long rule sets to NAT multiple networks, do interesting packet filtering between them and general everyday protecting-of-the-servers is nasty, long and irritating. The ipfw2 ``{}'' notation helps, but not much. What I meant was that creating complicated rulesets is klunky in ipfw and very, very nice in pf. That suggests to me that in some respects the underlying code is klunky/nice respectively. The whole ethos of how the filter works just feels *right* in pf.

      I read through the pf man page and was astounded how good it was. (I will wait until 1st May and OpenBSD 3.3 comes out, and do some speed tests against ipfw before making a final judgement though, obviously.) The way that pf has several different stages of filtering, and doesn't require you to use natd as a separate daemon (the 'nat' command in pf is a perfect example of the integration you talk about), already makes it a winner for my internal router. And the scrub command along with the easy anti-spoof and other bits (very intelligent keep-state stuff) would make it a perfect border router. Oh, plus the fact that OpenBSD comes with a built-in FTP proxy :)

      As for dedicated hardware: I've just built a very well-specced 6-port router (3 ports are gigabit) for around $1000. Try getting a Cisco that has as many features as pf with gigabit ports for that. We are a registered charity... :)

      I think that the more stuff gets loaded onto ipfw2, the slower and less reliable it will be. ipfw was not written flexibly enough in the first place. I agree, it was nice only having one main packet filter for FreeBSD, it meant the tutorials and howtos always worked :) I'm wondering just how well pf on FreeBSD is going to catch on, though: the momentum of ipfw may well keep pf out of the mainstream. Who knows...

      --
      - Oliver

      The right to bear arms is only slightly less stupid than the right to arm bears...
    6. Re:For those not keeping score... by Whyzzi · · Score: 3, Interesting

      When pf was in 3.0 -current, it wasn't ready for prime time. 3.1 -stable was alot better, lacked a few features, but way better. I (could be wrong , but I) am of the belief that they've added (not fixed) features since 3.2, and it is awesome.

      I'm using a 3.3 snapshot from March @ my small organization's 60pc firewall -- one as a bridge protecting my w2k server, the other as 3nic internet/nat+squid/dmz firewall -- both machines are utilizing altq to aggregate traffic nicely, on 64meg 166Mhz pentium classics no less. Squid tends to make my *uptime* pop over 1.00 once and awhile, but before I added squid the machine never broke a sweat.

      I played with linux's ipchains, and couldn't get used to the syntax ipchains required. I've used OpenBSD since 2.8, first with ipfilter (forced me to learn global string searching in vi), and gladly moved to pf. The macros and variable expansion simplify the configuration process considerably (my pf.conf is 217 lines long - macros, tcp options, altq, redirects and finally filters - all with adequate spacing and comments), and resetting the rules (likely other firewalling tools have this too) without losing state.

      Please, don't hesitate to order 3.3 when it is released, or at least check out pf in either FreeBSD or OpenBSD.

      --
      "BSD is about people pissing each other.." (Moid Vallat)
  4. hardly by DrSkwid · · Score: 2, Funny

    every post in this thread (except this one) explains what it is

    who needs google when we've got /. whiners ;)

    --
    There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  5. Re:Now we have to relearn FreeBSD networking?? by mnmn · · Score: 2, Insightful


    I never started this as a war between Linux and FreeBSD. I can see you are strongly biased one way. But my point is FreeBSD and Linux combined make for 6 different packet filtering tools. This does not help network administrators. The reason why :q! command in vi still works is because it was standardized in UNIX a long time ago and never changed.

    Of you still have a lot against Linux, well just take FreeBSD then. I hope we can use pf 7 years from now.

    --
    "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
  6. Re:Now we have to relearn FreeBSD networking?? by Ded+Bob · · Score: 2, Interesting

    The reason why :q! command in vi still works is because it was standardized in UNIX a long time ago and never changed.

    Having Emacs (yuck! :)) on your computer along with vi does not change :q!. This is the same.

    For Linux, it was closer to going from vi to ee to emacs for the base editor.

  7. Re:Now we have to relearn FreeBSD networking?? by phoenix_rizzen · · Score: 2, Insightful

    The syntax for ipchains / iptables is just horrible. It doesn't read anything close to English. The nice thing about IPFW / IPF / PF is that you can read a rule and udnerstand exactly what it is designed to do. I have yet to be find someone who can look at a NAT rule in IPTables and tell me exactly what it does without resorting to scrounging through manuals.

    The beauty of IPFW (or IPF or PF) is that the syntax hasn't changed all that much, even though new features have been added. The syntax for the Linux packet filter has changed 3 times in 3 releases.

    The other horrible thing about Linux packet filtering is that it only *just* got NAT figured out. Only took them 3 releases (and how many years??) to get that one. IPFW / IPF / PF have had that for several years now.

    I administer 12 FreeBSD IPFW firewalls, and 11 Linux IPChains firewalls. Can't wait until the summer when I can move those Linux boxes to FreeBSD with either IPFW or IPF. One less headache to worry about.