Slashdot Mirror


New PF on FreeBSD snapshot available

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."

58 comments

  1. No way... by Anonymous Coward · · Score: -1, Offtopic

    Not three days in a row.
    This would be HUGE.
    I could finally consider myself a man.
    Unless I don't hit submit fast enough...

  2. Speak like a true Mac fan! by Anonymous Coward · · Score: -1, Offtopic
    Mac Zealot Translator-o-matic

    Apple have come up with some innovative products, but their market share remains tiny. Sadly, though, many buyers have been mislead by the marketing and eye-candy, and desperately try to justify their overpriced purchases to themselves on forums around the Net. Let's see what they really mean...

    "MacOS X is everything Linux wants to be."
    "Despite the fact that Linux is just code and can't WANT to be anything, I truly believe that it'd love to be a single-vendor, single-platform, sluggish half-proprietary OS with dwindling market share. Linux would love to throw away its impressively growing corporate takeup for that."

    "Apple hardware is for real computer lovers."
    "It's no hassle to use a plethora of keyboard combos to make up for the patronising one-button mouse. Despite the fact that my hands have FIVE fingers, and multiple-buttons make Web browsing so much more pleasant, I prefer my computer to be treat me like a special-needs child."

    "Aqua makes me so much more productive!"
    "My non-techie friends drool over the transparency and scaling effects, even though UI research has shown that they add practically nothing to getting real work done. It feels like KDE 2 on a Pentium 200, and I can't change to a light and fast WM, but those drop-shadows must make me work so quickly!"

    "OSX shows that Apple is committed to open source."
    "OpenDarwin.org and its community of about 27 is surely not just a token gesture by Apple. Pretty much nobody uses pure Darwin, and all the crucial components of the system are closed and require me to spend money just to get major OS updates, but they're really helping the community somehow."

    "You get what you pay for with Apple hardware."
    "My iBook was made by in Taiwan by AlphaTop and has design and build quality flaws (needing foam sheets jammed in to stop the common problem of the keyboard scratching the screen). But it's silvery and cost far more than an x86 laptop of better spec, so it must be much higher quality!"

    "...blah blah MHz myth blah..."
    "Although there's truth in PPC being more elegant than x86, it's crushing that the top-of-the-range 1.5 GHz chip is slaughtered by the equivalent 3 GHz Pentium 4. However, Steve Jobs showed some vague Photoshop filter benchmarks at the last MacWorld, so I'm convinced."

  3. We are webchat of org you will be assimilated.... by Anonymous Coward · · Score: -1, Offtopic

    we will add your geekness to our own. Well at least ScootK and kc will, since they '0wn' webchat of org. I guess you could say they are the 'queens'

    I'm going to sue for slander. I AM ROOT HEAR ME FART.

  4. PF? by Anonymous Coward · · Score: 0

    What is PF? The eniter announcement refers only to PF, and doesn't give any info about the goals, purpose, or full name of PF.

    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:PF? by SolarFlux · · Score: 1

      Agreed. PF adds some very nice features that neither IPFW nor IPF have, and having ONE config file makes it simpler to manage. Anyone complaining that FreeBSD shouldn't have additional packet filters besides the defacto IPFW and the venerable IPF is doing the BSD community a disservice. If you don't want to use PF, don't use it; no need to complain. Freedom of choice is good.

      Those that have used all three packet filters know that PF is where it's at. Looking forward to seeing it added to the ports tree very soon. If you're installing a new system or have a test node handy, do yourself a favor and give PF a try. You'll be pleasantly surprised.

      As far as competition goes, as of now there is none. PF continues to improve drastically, while IPFW and IPF remain stale and stagnant (regarding new capabilities).

  5. Now we have to relearn FreeBSD networking?? by mnmn · · Score: -1, Troll


    Just like Linux, ipfwadm, then ipchains and iptables. Now FreeBSD ipfw, ipfilter now pf. This is by the way in addition to cisco IOS that you have to keep in mind which is similar but not the same.

    Hope noone comes up with NEW features later that demands new architectures.

    --
    "Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
    1. 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.

    2. Re:Now we have to relearn FreeBSD networking?? by Deagol · · Score: 1
      Heck, the packet filters themselves are crud.

      What's your beef with Linux's filters? I've found iptables to be really nice -- much better than ipchains (never used ipfwadm).

      I just installed NetBSD for the first time (on VMWare on my Redhat box), so I guess I'll get a chance to see first-hand the *BSD side of packet filtering. Maybe I'll have a different opinion of iptabels in a couple of months.

    3. Re:Now we have to relearn FreeBSD networking?? by Anonymous Coward · · Score: 0

      compeltely incompatible packet filter
      In FreeBSD, there's IPFW *or* IPFilter *or* Packet Filter

      In Linux, each program is backwards compatible with the previous major kernels. You can run ipchains and it's modules on linux 2.4, even though 2.4 uses iptables and so forth.

      Can you run freebsd 3.x software on freebsd 4.x?

    4. Re:Now we have to relearn FreeBSD networking?? by Anonymous Coward · · Score: 0

      Yes. You can even remove that support if you don't want a bloated kernel. You can 3.x software on 5.0x as well.

    5. Re:Now we have to relearn FreeBSD networking?? by Istealmymusic · · Score: 1, Informative
      In Linux, each program is backwards compatible with the previous major kernels. You can run ipchains and it's modules on linux 2.4, even though 2.4 uses iptables and so forth.

      Can you run freebsd 3.x software on freebsd 4.x?

      The AC already replied, but I just want to point out he or she is correct. FreeBSD 5.0, by default, includes compatiable libraries and interfaces to run older code. This includes compat2, compat3, and (with the release of 5.0) compat4. There are kernel options, such as COMPAT_FREEBSD4, which can be removed if you wish to sacrifice the ability to run older 4.0 applications for some space. You can even enable the syscall.master option COMPAT4 to transparently wrap 4.0 syscalls when appropriate.

      Therefore:

      • In Linux, each program is backwards compatible with the previous major kernels.
      • In FreeBSD, each program is backwards compatible with the previous major and minor kernels
      • In Windows, each program is backwards compatible with the previous versions of Windows and DOS

      You have no argument, as all major operating systems support backwards compatibility in one form or another. Programmers don't just break interfaces at their whim (unless they submit Linux patches). In fact, I would go as far to say that FreeBSD is more backwards compatible than many other operating systems: FreeBSD can run Linux executables.

      --
      "The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
    6. 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
    7. 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.

    8. 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.

    9. Re:Now we have to relearn FreeBSD networking?? by phoenix_rizzen · · Score: 1

      Actually, your analogy is off.

      If Linux-land, the analogy is: 2.0 had vi and all was well. 2.2 removed vi and added emacs. 2.4 removed emacs and added pico. Three kernel releases, three new editors to learn. Sure, each editor includes a very rudimentary command emulator for the previous editors, but nobody can use them for real work.

      In BSD-land, the analogy is: vi was added. A few releases later, emacs was added as an option. A few releases later, pico was added as an option. Users have the choice of using any of the three editors, as they please.

      Notice the difference??

      There are 4 packet filters to choose from: IPFW, IPF, PF, and whichever filter your Linux kernel uses. At least in BSD-land, you don't have to throw away your prior knowledge when a new OS release is made.

    10. Re:Now we have to relearn FreeBSD networking?? by Deagol · · Score: 1
      The syntax for ipchains / iptables is just horrible. It doesn't read anything close to English.

      I could say the same thing for perl, but I'd have a hard time coming down as hard on it as you have on iptables. However, it's all I've ever known in the world of filtering (except for Cisco's and AIX's filter rules). I guess syntax is a matter of taste and what we're comfortable with.

      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.

      Ah, now a technical reason. Didn't ipchains have NAT, or is masqerading a totally different conecpt? I used to have multiple clients routing via an ipchains box when I had broadband.

      Since you've obviously run both side by side, can you comment on the speed of both? There's measurable overhead when enabling iptables (crude tests on low-end hadware, but I was able to clock a difference in load). Is the same true for the *BSDs?

    11. Re:Now we have to relearn FreeBSD networking?? by Anonymous Coward · · Score: 0

      (not OP)

      I could say the same thing for perl, but I'd have a hard time coming down as hard on it as you have on iptables.

      Perl does many things, scripting languages with similar power have similar learning curves.

      iptables does few, all of which can be done with pf with much less effort.

    12. Re:Now we have to relearn FreeBSD networking?? by Anonymous Coward · · Score: 0
      In Windows, each program is backwards compatible with the previous versions of Windows and DOS
      Yeah right. While some programs created today for Windows might run on older versions, it's despite Microsoft's best efforts. Filesystems have changed, the APIs have changed, you need tons upon tons of dll downloads to make them work, and these aren't readily available from Microsoft anymore (you don't want to get your downloads from www.micRosfTdLLs.com, do you?) because Microsoft is trying hard to phase out the older versions.
    13. Re:Now we have to relearn FreeBSD networking?? by phoenix_rizzen · · Score: 1

      IPChains had masquerading, where all outgoing packets were given a single source IP, thus allowing for a LAN of computers to appear as one. However, it didn't do NAT in that you couldn't have multiple external IPs for that same LAN, and you couldn't NAT incoming traffic to create a DMZ with each computer having it's own (or sharing a couple) or public IP addresses. There were a few other NAT situations that couldn't be done using Linux packet filters.

      IPTables was the first to support NAT, incoming, outgoing, and all combinations. However, the syntax for it is horrible (IMO).

      As for speed, IPFilter and PF are the speed champs when NAT and/or stateful filtering is used. All packet filtering for these is done in-kernel and is optimised out the yin-yang. IPFW is just as fast as these two for simple packet filtering, but is a little slower when stateful filtering is enabled. And, because the natd daemon works in userland, enabling NAT really slows things down, due all the context switching and copying of data from kernel to userland. However, IPFW/NATd is plenty fast enough for most situation (small to medium LANs numbering into the hundreds). For enterprise-wide filtering (thousands of clients) you definitely want to use IPF or PF.

      Personally, I just don't like the syntax of IPChains and IPTables. I also don't like the lack of features, or the fact that everything changes with each new kernel release.

  6. For the acronym impaired by spitzak · · Score: 1
    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.

  7. Fer crisakes!!!!!!! Editors, do you fscking job!!! by fm6 · · Score: -1, Troll

    When you post a story like this, say "pf (a packet filter package)" or something like that. Otherwise people have to click a half dozen times just to find out if they're interested in the story!

  8. Sheesh by omega9 · · Score: 0, Flamebait

    No shit. Screw me for not knowing what PF is, but it's just common sense to provide some length of explaination of your subject. I'm scared to click on any of the links for fear that the posted text is just a copy/paste from another source.

    Futile, really, to see this complaint come up so many times and realise that the editors really don't give a shit, or at least don't care to offer a rebutle. I realize it's not the most professional approach to post stories relating to how badly they post stories. But I'm guessing their image isn't helped by all of these legitimized complaints. How much longer can they take themselves seriously?

    The same can be stated in financial terms. Yes, as "editors" you're all mostly very lame (except that last book review was excellent!), but I do still come here on a semi-daily basis to dig through the threads. However, Moz/Phirebird/foo are set to block images from this server. Our university proxy has even been set to do the same. I'm even starting to get a bad taste in my mouth for people who advertise here.

    The biggest trolls here are the editors.

    --
    I'm against picketing, but I don't know how to show it.
  9. Re:Fer crisakes!!!!!!! Editors, do you fscking job by jo42 · · Score: -1, Offtopic

    No, no, no! "pf" is 'fudge packer' backwards...

  10. 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 Mark+Pitman · · Score: 1
      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.

    2. Re:For those not keeping score... by drdink · · Score: 1
      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'm afraid that FreeBSD's firewalling could go the way of Linux, where "firewall" means it could be ipfwadm, ipchains, or whatever they use today.

      FreeBSD has already axed the NODEVFS option out of -CURRENT since it was no longer really necessary with the new devfs code. I don't see how having pf is any different, when the featureset of pf could just be merged back into ipfilter or ipfw instead.

      --
      Beware, Nugget is watching... See?
    3. 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.

    4. Re:For those not keeping score... by Anonymous Coward · · Score: 0

      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

      Who do you think you are, telling some free software developer how to spend his time?

      If that's your opinion, go do it your damn self.

      I'll go hack on porting OpenBSD to run on my desk-lamp (unless its your opinion that its a waste of time of course)

    5. Re:For those not keeping score... by drdink · · Score: 1
      As I stated above, it is my opinion. I am not the dictator of development, and was merely pointing out what I thought would be more productive. My real concern is if pf ends up being lumped into the FreeBSD source tree, since it will add bloat by adding new interfaces for existing mechanisms.

      I don't care what you do with your lamp, but is is my opinion that you could spend your time doing much more productive things. Besides, NetBSD likely already runs on your lamp.

      --
      Beware, Nugget is watching... See?
    6. 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...
    7. 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
    8. 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?
    9. 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...
    10. Re:For those not keeping score... by JJahn · · Score: 1

      You know, punch cards worked just fine too.

    11. Re:For those not keeping score... by frost22 · · Score: 1
      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 own thing.

      I agree with the original poster. FreeBSD needs another packet filtering system about as necessary as the proverbial fish needs that bicycle. If there is room for improvement (and there always is :-), improve ipfw !
      --
      ...and here I stand, with all my lore, poor fool, no wiser than before.
    12. Re:For those not keeping score... by frost22 · · Score: 0, Flamebait
      I read through the pf man page and was astounded how good it was.
      What an incredible bullshit.

      The manpage you quote is documenting a programmer's interface with IOCTLs and c structs. It neither proveides a usefull overview of pf nor does it tell you how to build rules with it.

      If you read that and found it better than FreeBSD's concise and well written ipfw(8) manpage you must have smoked some very heavy stuff.
      --
      ...and here I stand, with all my lore, poor fool, no wiser than before.
    13. Re:For those not keeping score... by frost22 · · Score: 1
      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, Excel is a graphics Program and Powerpoint has a Wordprocessor funtion).

      Under Unix a tool is supposed to do on e thing, and do it right. ipfw(8), that is, the control program, does this - it controls the filtering facility.

      If you want more complex rule sets, write them in shell scripts (as I do), or have them preprocessed by cpp or m4 or whetever.
      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.
      This may or may not be correct, but you totally failed to make that case.
      --
      ...and here I stand, with all my lore, poor fool, no wiser than before.
    14. Re:For those not keeping score... by Huge+Pi+Removal · · Score: 1

      Sorry, the pf.conf manpage... my mistake.

      http://www.openbsd.org/cgi-bin/man.cgi?query=pf.co nf&apropos=0&sektion=0&manpath=OpenBSD+Current&arc h=i386&format=html

      Just look at all the little details they throw in. You don't *just* get tables, you can define them as being 'const' too, which is rather handy... The whole thing is carefully designed, not thrown together.

      --
      - Oliver

      The right to bear arms is only slightly less stupid than the right to arm bears...
    15. Re:For those not keeping score... by Huge+Pi+Removal · · Score: 1

      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 it's a great firewall. Firewalls have to do more than just plain old packet filtering with a little keep-state thrown in, and they have to do it efficiently. My case is that ipfw started out as a packet filter, and you can't shove lots of other stuff on top of that and expect it to be as good as something with everything (from nat to altq...) built-in (or provisions put in) from the start.

      --
      - Oliver

      The right to bear arms is only slightly less stupid than the right to arm bears...
    16. 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)
    17. Re:For those not keeping score... by Anonymous Coward · · Score: 0

      FreeBSD isn't doing it. Someone else just thinks it would be neatsy keen for add PF support to FreeBSD. Don't look a gift horse in the mouth.

    18. Re:For those not keeping score... by Anonymous Coward · · Score: 1

      Actually, ipfw2 currently has portability problems with Sparc64, I believe. Hopefully L. Rizzo or someone else will fix that, though.

    19. Re:For those not keeping score... by Anonymous Coward · · Score: 0

      True. User ppp is also like that. Easy to set up perhaps, but lots of extra crap tacked on, including its own firewall. I think it needs to be redesigned at some point.

    20. Re:For those not keeping score... by Anonymous Coward · · Score: 0


      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.


      No, it's: if I can't use my old shovel any more, I make a new one. The old one works on sand, but I need to dig dirt now. I make one able to shovel heavy mud and gravel, and I won't ever have to make another one.

      The reason they redid the packet filter is because of a licensing issue, not just because they thought they could write a better one.

    21. Re:For those not keeping score... by vesamies · · Score: 1

      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.

    22. Re:For those not keeping score... by hununu · · Score: 1

      Because as I see it, no one is adding code to ipfw and there is a lot of interested people in getting pf into FreeBSD. I'm just being pragmatic.

    23. Re:For those not keeping score... by drsmithy · · Score: 1
      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 gained the ability to synchronise state across multiple firewalls, which really is a killer feature. IPF doesn't have it in a stable, supported or currently-in-development form and IPFW doesn't have it at all. If the OpenBSD crew can get working state synchronisation into OpenBSD, then it probably won't be long after that that I start migrating the few dozen firewalls we have here on campus will begin migrating to it from IPF on FreeBSD.

      On top of that there are the all the other things that pf just does better.

    24. Re:For those not keeping score... by Anonymous Coward · · Score: 0

      Your point is good, but your logic is bad...

      Have you looked at the rework of ipfw which is in FreeBSD 5.0-CURRENT and known as ipfw2?

      Both ipfilter and ipfw have been around for a long time and alraedy proven themselves to work well.

      At least one of these is irrelevant.

      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.

      I also prefer FreeBSD over OpenBSD, though the reasons for that aren't really relevant to this conversation.

      Presumably for ease of config., proven stability, flexibility, and how tightly integrated it is with the other things that you are using, yes?

      (heh, security conspicuously missing ;)

    25. Re:For those not keeping score... by R.Caley · · Score: 1
      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 enough to need anything fancy,

      --
      _O_
      .|<
      The named which can be named is not the true named
  11. 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
  12. Re:Fer crisakes!!!!!!! Editors, do you fscking job by fm6 · · Score: -1, Flamebait

    Are you sure it's not "pudge facker"?

  13. Grow up, troll by fm6 · · Score: 0

    Gee, I knew there was a reason I should have taken Prescience 101. Then I could read Slashdot posts before they're written!!

    1. Re:Grow up, troll by Anonymous Coward · · Score: 0

      Or you could read the article before you posted. Or you could do a google search. Or you could ignore the article, or you could ignore BSD articles if you don't know anything about them.

  14. *BSD is dying by Anonymous Coward · · Score: -1, Flamebait
    It is official; Netcraft now confirms: *BSD is dying

    One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

    You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

    FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

    Let's keep to the facts and look at the numbers.

    OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

    Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

    All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

    Fact: *BSD is dying

  15. Means more choice, I think we Do need it by Anonymous Coward · · Score: 1, Informative

    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

  16. POOR, POOR THEO DE RAADT by Anonymous Coward · · Score: -1, Troll

    EVERYONE ALWAYS RIPS OFF OPENBASD, NEVER GIVING ANYTHING BACK. I BET IF THEO NU WHAT A BUNCH OF CRAZED THEIVES YOU OSS FUCKS WERE WHEN HE STARTED, HE"D HAVE CHOSEN TO BECOME A WATCHMAKER INSTEAD!!!
    --
    # Important Stuff: Please try to keep posts on topic.
    # Try to reply to other people's comments instead of starting new threads.
    # Read other people's messages before posting your own to avoid simply duplicating what has already been said.
    # Use a clear subject that describes what your message is about.
    # Offtopic, Inflammatory, Inappropriate, Illegal, or Offensive comments might be moderated. (You can read everything, even moderated posts, by adjusting your threshold on the User Preferences Page)

    Problems regarding accounts or comment posting should be sent to CowboyNeal.

    [ faq | code | awards | journals | subscribe | older stuff | rob's page | preferences | submit story | advertising | supporters | past polls | topics | about | bugs | jobs | hof ]

  17. Re:*BSD is dying, so let's FUCK IT!! by Anonymous Coward · · Score: 0

    From an9420@anon.penet.fi Sat Oct 9 13:37:06 EET 1993

    this was an anonymous post, i dont even remember where i found it. it will, however, be expanded on whenever i find the time for it. in the mean time, thanks to Theoderich and too all of you, have fun.

    decayed kisses,
    the pink and purple
    tinsel fairy of love
    and necrophilia

    NECROPHILIA

    by Theoderich
    I: Introduction

    Very few text files have been written regarding the sexual tendencies and practices of necrophiliacs. While most people would prefer to believe that we do not exist we most certainly do as is obvious to anyone who visits a cemetery during our nightly rampages.

    Necrophiliacs prefer to go about their business alone; sharing is not a part of this alternative lifestyle as the corpse usually wears out fairly quickly. This is not to say that the occasional orgy involving four or five necrophiliacs and about a dozen or so corpses does not occur, but it is very rare. In this file I will describe common (and some uncommon) techniques which necrophiliacs use to gain satisfaction from their stiff partners. Hopefully these vivid descriptions will encourage you to go out to your local cemetery and to join our ranks!

    II: Finding a partner

    Finding a partner for your necrophiliac activities is definitely the hardest part. You not only have to gain access to the corpse but you also have to find one which suits your tastes. Granted, some
    necrophiliacs would screw roadkill if given the chance but most of us are more discriminating. Your chances depend upon where you pick up your date. If you have access to a morgue it would definitely be your best bet as the corpses there are usually the freshest and have not yet been treated for burial. They may be a bit chilly because they've been lying in the meat locker for days but that really shouldn't make a big difference to the determined necrophiliac. Cemeteries are a bit harder to deal with as finding a screwable corpse is harder to do.However, if you know how to interpret signs this shouldn't be a problem.
    If a grave consists of a mound of fresh dirt and is covered with flowers,chances are that the stiff hasn't been laying here for too long. Rotting flowers on the mound usually hint to the state of the corpse as well.
    Some people are exclusively into 'porking the bone', i.e. sex with skeletons. In this case you can dig up almost any grave and hope that the inhabitant hasn't yet disintegrated into dust. Try to scope out a fairly secluded cemetery for your passions unless you like a sense of danger to go along with the sex. Having anyone catch you in the act is NOT fun, and if you're picked up by a cop chances are that you won't be able to screw anything but Bubba behind bars for the next few decades.
    People are generally not understanding of the necrophiliac lifestyle, so it will probably be a long time before we can come out of the closet.

    III: Preparation

    Depending upon where you are at this point you'll have either a little or a lot of work to do. The person in the morgue will obviously have to do little more than to open the locker, pull the corpse out and bang away. If you're one of the cemetery people you'll have more work to do. An experienced necrophiliac is always equipped with the bare essentials: a shovel, vaseline and a box of rubbers. Why the shovel is needed should be obvious, but if the ground is hard then you might need more equipment to dig up your date. Vaseline is used to loosen the corpse up a bit. This makes it less likely for a body part to break off while
    you're having fun and it also prevents your mantool from becoming too irritated while screwing the dried out pussy. The BOX of condoms is used to play it safe; no necrophiliac should be without it. You never know which STDs your partner had during his/her lifetime, and believe me, it doesn't get any better after the person dies. You can put on more than one rubber for extra protection if it is warranted, but screwing a corpse without