OpenBSD Journal

Porting The PF Stateful Packet Filter

Contributed by jose on from the other-flavors-are-juicy dept.

an anonymous reader send this one in:
"KernelTrap offers an in depth look at the recent efforts to port OpenBSD's stateful packet filter, pf, to other operating systems. The article includes interviews from Pyun Yong Hyeon who's working on the FreeBSD port, pf creator Daniel Hartmeier, pf developer Henning Brauer and OpenBSD creator Theo de Raadt. In addition to discussing recent porting efforts, the last half of the article focuses on all the new features in pf that will be available with the May 1'st release of OpenBSD 3.3."
You have to admit it's pretty cool to have features in the kernel that people want to port around. PF has attracted the interest of NetBSD and FreeBSD hackers, but so far no one else seems to be porting it elsewhere (anyone have any info on this to share?).

(Comments are closed)

Comments

  1. By Xenotrope () on

    I'm excited to hear about all the work that's gone into the new pf that will appear in OpenBSD 3.3. My concern is that my current firewall runs off an old snapshot of 3.2-beta with about 300 days of uptime. I rely on this firewall every minute of every day.

    Will the old /etc/pf.conf file still run cleanly and correctly given the extensive changes to the new pf syntax? I don't have a problem with updating my old ruleset to take advantage of the new features, but similarly I want to be able to tweak the old ruleset to the new syntax at my own convenience. In other words, I desire to upgrade the firewall to OpenBSD 3.3 on a Tuesday, and not worry about rewriting the ruleset until a week after Friday.

    Even though there's been plenty of publicity about the new features of pf, I haven't heard anyone mention if it will be backwards compatible or not.

    Comments

    1. By Daniel Hartmeier () daniel@benzedrine.cx on http://www.benzedrine.cx/pf.html

      There are only minor changes which could cause your 3.2 ruleset to not load on 3.3.

      They are related to interface name -> address translation in the parser (if you're not using dynamic translation, like in 'nat on $ext_if ... -> $ext_if'). If the interface has multiple addresses/aliases, pfctl in 3.3 will force you to explicitely use one of them instead of the interface name.

      If you get an error about ambiguous address families, you can just add 'inet' or 'inet6' to the rule to make it clear (and this loads on both 3.2 and 3.3).

      So, in the worst case, you get a couple of such errors with 3.3, but they're easily solved, and the new ruleset will still load on 3.2. More likely, the ruleset will just load without a problem.

    2. By lx () on

      "Will the old /etc/pf.conf file still run cleanly and correctly given
      the extensive changes to the new pf syntax?"

      Unfortunately not, since it's all in German now. A migration
      tool would be pretty trivial to write, however.

      Comments

      1. By Xenotrope () on

        Ja. Danke.

  2. By Anonymous Coward () on

    So when is pf going to be ported to the Linux kernel?

    Comments

    1. By Anonymous Coward () on


      Why, they have iptables!

      Comments

      1. By Anonymous Coward () on

        because iptables is terrible

      2. By Anonymous Coward () on

        because iptables sux - yesterday I had to configure a firewall with iptables and was reminded why I prefer pf's elegance and simplicity!

      3. By Anonymous Coward () on

        Okay so Linux has IPtables; true
        Does that mean that Linux users shouldn't have choice?

        Daniel has a nice analysis between IPTables, PF and IPF. It states (in short) that PF and IPTables have roughtly the same scalability and speed. IPF lacks clearly behind.

        When it comes to configurability, features and such then PF wins over any firewall i know, including IPF and IPTables.

        So why not give Linux users the choice of PF? I see no reason why not.

        Comments

        1. By Matt () on

          because there are 1000 linux ninnies for every openbsder and we shouldn't spend a rediculous amount of time porting applications for their usage. Granted, it is a good thing that they designed the PF code with portability in mind, but the acctual work to convert should be done by the linux crowd, they have more than enough manpower to make it happen if they really want it.

          of course the developers can spend their time on anything they want, this is just a hobby to many of them (hobby meaning they see no financial gain). it would be nice to concentrate efforts on adding more features to pf and openbsd and let the linux folks take care of themselves, they can do fine on their own.

          the only real advantage to this would possibly be more developers for pf, which could add more features for us at a faster rate.

          Comments

          1. By Henning () henning@openbsd.org on mailto:henning@openbsd.org

            "more developers" is the last thing I want. I think the current team is about perfectly sized.

        2. By AnonymousCanuck () on

          When it comes to configurability, features and such then PF wins over any firewall i know, including IPF and IPTables.

          Linux NetFilter (aka iptables) has some advanced router features that rival Cisco. Such as the ability to easily "loadbalance" TCP streams between two very different Internet providers with NAT. There is some really funky routeing that you can pull useing 'mark' rules and seperate routeing tables for each 'mark.' Linux supports 127 or 256 routeing tables some of which are spoken for. There are also more QoS and packet shapeing features. If OpenBSD has these features I have been unable to find them documented.

          I think that the PF state table is better, but have been unable to test this. It is possible that state and NAT are just expensive and that OpenBSD would get hammered just as badly as Linux when I update the status of the 25000+ CounterStrike servers. (that would be 25000+ NATed udp connections in the state table)

          I like PF because of its easy to read config file, but I prefer the power and tweakability of NetFilter despite the learning curve.

          (OpenBSD also needs better PPPoE. Recall the FreeBSD/NetBSD/OpenBSD/Linux tests from December . PPPoE is an unfortunate reality for some of us.)

          Comments

          1. By Anonymous Coward () on

            what is up with the HTML posting option? I only put in a pair of em tags not the multiple now found in the post.

          2. By Anonymous Coward () on

            PF in 3.3 will have loadbalancing. Not sure if that's what you seek for. Also, "According to the comments in this (http://kerneltrap.org/node.php?id=477&PHPSESSID=6fc963cd0c88dc7d8ca23e620710b006) story, IPTables does not do stateful inspection/filtering, only connection tracking. As to how that would impact your needs, that is something you need to investigate. To me it sounds like a shortcoming in IPTables, one that hopefully will be changed." taken from a comment at the kerneltrap article :-)

            Comments

            1. By Anonymous Coward () on

              According to netfilter.org:

              The netfilter/iptables project is the Linux 2.4.x / 2.5.x firewalling subsystem.It delivers you the functionality of packet filtering (stateless or stateful), all different kinds of NAT (Network Address Translation) and packet mangling.

              I think I will trust the source not an AC in a forum.

    2. By Anonymous Coward () on

      That is a major undertaking because, if you don't know, pf lives in kernel land. Henning and I have it on the current roadmap and speculate if all goes well we will have working code by the end of the year.

      Comments

      1. By Anonymous Coward () on

        Henning and I have it on the current roadmap and speculate if all goes well we will have working code by the end of the year.

        Is this for real or are you pulling my leg? Is there any documentation up or a future website for the project?

        Comments

        1. By henning () henning@openbsd.org on mailto:henning@openbsd.org

          I am not working on pf ports to other OSs, I don't plan any, and it's not very likely that I will anytime soon.

    3. By Anonymous Coward () on

      who cares? I do not, and doubt anyone around here would.

      Comments

      1. By Anonymous Coward () on

        i do

        speak for yourself, thanks

    4. By Anonymous Coward () on

      pf on Linux was ported to MicroBSD 2000 seconds ago.

    5. By W () on

      No, it was actually ported to MicroBSD *before* daniel created it. They 0wn.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]