Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
BSD Operating Systems

New PF on FreeBSD snapshot available 58

Posted by michael 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."
This discussion has been archived. No new comments can be posted.

New PF on FreeBSD snapshot available More

New PF on FreeBSD snapshot available

Comments Filter:
  • PF = Packet Filter. It is used for networking and firewalls. Apparently there are several alternatives for FreeBSD and this is one of them.

    It might be helpful to provide rudimentary information like this in the slashdot articles.

  • For those not keeping score... (Score:3, Informative)

    by drdink ( 77 ) <smkelly+slashdot@zombie.org> on Thursday April 24, 2003 @02:36PM (#5802255) Homepage
    PF is the Packet Filter used in the latest releases of OpenBSD [openbsd.org]. OpenBSD developed pf after a licensing dispute with Darren Reed basically resulted in him telling OpenBSD to go to hell.

    FreeBSD [freebsd.org], up to now, has had two different firewalling methods. First off, there is the natively developed ipfw [freebsd.org] tool, which recently got a renovation and is now ipfw2 in -CURRENT. The alternative to ipfw is Darren Reed's ipfilter [slashdot.org], 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.

    • There is no reason FreeBSD needs to dig a deeper firewalling grave for itself like OpenBSD has done.

      Can you explain what you mean by this? It's not a troll, I am genuinely interested in what you mean.

      • It means that wheel reinvention should be kept to a minimum, especially inside the kernel. Both ipfilter and ipfw require some sort of kernel backend, and I am hedging my bets on them having different hooks. Adding pf seems like just another thing to learn. Why reinvent the tools we have just to add features to them if we can add the feature to the tool we already have? If I want a shovel with a steel handle, I don't make a brand new shovel. I take my already existing shovel and fit a new handle onto it. I'
        • 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, noth

          • In order to get pf's nice features into ipfilter, you would have brain-wash Darren Reed I guess. :-)

            Why do you ignore ipfw here ?

            ipfw is FreeBSD's very own and native packet filtering framework. It already has a number of those features ascribed to pf, and it works quite well with FreeBSD.

            The very reason pf exists is that Theo and the Gang suffered from a mild rash of NIH when they needed packet filtering code after their run-in with the Ipf guy. Instead of just porting ipfw, they choose to do their ow

        • You know, punch cards worked just fine too.
    • If you read the man page for ipfw [freebsd.org] and compare & contrast with the man page for pf [openbsd.org], 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 :)
      • 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

        • 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
          • The macros and variable expansion simplify the configuration process considerably

            On this one I think the way IPFW is used on FBSD is defintley the Right Thing. You just add rules in a shell script and so you have the variable substitution, conditionals, tests and definable functions in a syntax everyone should be familair with.

            Isn't the tsandard linux ipWHATEVERITISTHISWEEK filter similar? I set up some rules once some time ago and seem to remember it was a shellscript, though I didn't do anything big e

      • 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 everyo

        • 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

        • Re:For those not keeping score... (Score:1)

          by Anonymous Coward
          Actually, ipfw2 currently has portability problems with Sparc64, I believe. Hopefully L. Rizzo or someone else will fix that, though.
        • 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.

          No they wouldn't, unless their company has a _lot_ of money to throw away. Firewalling devices, particularly that can handle links >100MB are *very* expensive. And you can take that large number and multiply it several times if you want anything resembling redundancy.

          I really want to see pf on FreeBSD. It has recently

      • 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).

        This is plain nonsense. Ipfw has all the bells and whistels you need, and quite some more. And, sorry, variable expansion under Unix is done in a shell or a macro preprocessor and not in the firewall control utility.

        You (and maybe the pf author, too) apparently suffer from the Microsoft Word desease (Word calculates tables

        • I think you're missing the point... pf doesn't have bells and whistles. It has a lot of useful functions, that make life for the administrator of a complex firewall much, much simpler. E.g. Tables are a very speed-efficient way of having large groups of IP addresses: you aren't going to get that sort of functionality expanding on the command line. The fact that these functions *are* integrated with the firewall make things speedier and easier. It's not bloat.

          Yes, ipfw is a great filter. That doesn't mean i
    • FYI, ipfilter is not under BSD license, I bet the OpenBSD developers did not like putting their effort to deleveloping non BSD licensed software, with more strings attached... For this reason, I think that also NetBSD should have pf.

  • Means more choice, I think we Do need it (Score:1, Informative)

    by Anonymous Coward
    PF means more choice and its not like it takes that much more space in the distribution
    Also means I will have to port my "ROQ" script to it as well so people can easily set it up on FreeBSD 5.1 go to http://www.roq.com/bsd/ and you will see what I mean

Slashdot Top Deals

Genius is ten percent inspiration and fifty percent capital gains.

Close