OpenBSD Journal

Unofficial web frontend for pf - pfw

Contributed by grey on from the pf front ends sure seem to be popular of late dept.

An anonymous tipster points us to yet another web front end for pf. The site can be found here: and the archived announcement from the pf mailing list may be found here.

[Editors note: I don't use pf front ends currently, so I can't comment on general usability of one relative to another. That said, at least this one is under a BSD license, and doesn't require Java which may make life more difficult for OpenBSD users. I am intrigued (if that's the right word?) by the apparent popularity of pf front end projects though as this is at least the third such announcement since deadly was reborn as undeadly.]

(Comments are closed)

  1. By StatiK76 ( on

    wow. I think there are more pf frontend developers, than there is pf frontend users. Are all of these truly newsworthy? StatiK76

    1. By Anonymous Coward ( on

      While those aren't usefull for us, they're helpfull to push OpenBSD on embedded network appliances for end users (as does linux on linksys APs).

  2. By Anonymous Coward ( on

    Glad you got something working for yourself. Not that I do not applaud your work, but I strong disagree with the choice of scripting languages you used, php. I think if the community is going to fully accept a web based frontend, especially one that has to reside on the firewall itself, it sure use what is in the base if at all possible - Perl, or even C if anyone so attemps. - just my opinion ;)

    1. By Mark Patterson ( on

      I'm looking at web scripting languages at present, and I'm wondering why you perfer Perl to PHP? Is it for security reasons? Could you point me to a study? And what would you think of Python?

      1. By Simon Dassow ( janus X errornet X de on

        ...its not in the base(!) and we all want something that runs seamless out of the box (just like our fine OS). More arguments required? ;-P

    2. By daniel ( on

      Here comes the beauty of open source:
      you don't like a php frontend? somebody (or you) will write another frontend in another language.. so were is the problem? look for another implementation! :)

      1. By RC ( on

        you don't like a php frontend? somebody (or you) will write another frontend in another language.. so were is the problem?

        Well, it's the problem that everyone writing something that just suits themselves, just makes a situation where everyone has their own that only they use. Not pretty...

        Why not have every single person fork OpenBSD, and make their own OS? Re-write everything in java!

        What a mess the world of software would be in.

        1. By Howard Owen ( on

          It's only a mess if none of the options is regarded as clearly superior by the user community. If one or a handful are so regarded, they become the standards. For example, I could imagine that OpenBSD sysadmins, perhaps more than those of any other OS, might regard the use of software in the base OS as a Really Good Thing. Thus they might choose a PF frontend that has this property, or write one if it didn't already exist.

          But this is only my imagination. The proof of whether a PF front end like that is really better for users, or if a PF front end is really needed at all, will be whether or not one gets widely adopted. Where's the "mess" in that?

          1. By mike ( on

            waste of resources? The thing I find most interesting about OpSrc is that people "congregate" across boundaries to leverage knowledge and skill against lack of means in a way that is probably unprecedented. Software darwinism implies that M$ is best because everyone and his/her uncle uses it... so umm, "PF Front-End Developers Unite!"

    3. By kokamomi ( on

      yeah, and while we're at it, why even rely on apache? having your firewall serving web pages is probably a bad idea, and if we're not serving web pages except for this interface, we don't really need an elephant doing it. but i'm sure these people have a good reason for doing what they are doing.

      i'd prefer a concise daemon interfacing with pf, serving it's own administration and monitoring pages: i'd say that we would have something for most users... and furthermore, if this interface would focus on how the user perceives his networking context and what he is trying to acheive and what level of involvement he's ready to put in, rather than just be a replacement for your favourite text editor, then i'd say that we are on a good way into mainstream hardware filtering.

      pf.conf is far more human readable than iptables etc, but this is probably not simple enough.

      so what's a good interface?

      1. idiot safe, scenario based configuration view. (do you want to share a connection? do you want to filter external attacs, what's your isp-provided info? does any of your computers act as a server or a p2p client, and wich ones? etc...)

      2. possibly an intermediate configuration view: enable dmz, disable ftp-proxy, enable and configure spamd, etc.

      3. advanced configuration view, probably editing pf.conf through a text-field would be adequate.

      4. help system, drawn from man pages and faq.

      5. self contained daemon with minimum privs. integrated tight http-server (based on thttpd, for instance).

      6. good monitoring and incident logging


      hell, it's probably even worth a commercial pitch. put this a stripped openbsd and this daemon in a small cheapo box with 2+ ethernet jacks and you have a netgear/d-link killer. what do you think?

      1. By click46 ( on

        I think someone is already working on it ;)

  3. By johannes ( on

    Is it just a rule generator or does it really interface with pfctl or even via sysctl? I couldn't find any information about this on the web page.
    Thank you!

  4. By daniel ( on

    Here comes another script designed FOR OPENBSD, requiring apache WITHOUT chroot... breaking a bit of security for a frontend that will be used only by administrator and maybe not so often, so I wonder:

    aren't there other ways to do all this stuff from inside the chroot?
    how about creating /dev/pf inside chroot and hardlinking pf.conf?

    However, keep up the good work! :)


    1. By Anonymous Coward ( on

      It is possible to install the apache to listen only on localhost and then ssh into the fw with portforwarding your browser, thats how I would do it anyway. It would give you strong authentication, encrypted management channel and a non-accessable "unsafe" installation of the webserver, however being paranoid I would not let the ssh server be accessible from any other interfaces than the "trusted" internal.//P


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