If you are reading this because you are considering moving your setup to PF from some other system, this section is for you.
If you want to use PF, you need to install and run a BSD system such as OpenBSD, FreeBSD, NetBSD, or DragonFly BSD. These are all fine operating systems, but my personal favorite is OpenBSD, mainly because that is the operating system where essentially all PF development happens, and I find the developers’ and the system’s no-nonsense approach refreshing.
Occasionally, minor changes and bug fixes trickle back to the main PF code base from the PF implementations on other systems, but the newest, most up-to-date PF code is always to be found on OpenBSD. Some of the features described in this book are available only in the most recent versions of OpenBSD. The other BSDs tend to port the latest released PF version from OpenBSD to their code bases in time for their next release, but synchronized updates are far from guaranteed, and the lag is sometimes considerable.
If you are planning to run PF on FreeBSD, NetBSD, DragonFly BSD, or another system, you should check your system’s release notes and other documentation for information about which version of PF is included.
The differences and similarities between Linux and BSD are potentially a large topic if you probe deeply, but if you have a reasonable command of the basics, it should not take too long for you to feel right at home with the BSD way of doing things. In the rest of this book, I will assume that you can find your way around the basics of BSD network configuration. So, if you are more familiar with configuring Linux or other systems than you are with BSD, it is worth noting a few points about BSD configuration.
Linux and BSD use different conventions for naming network interfaces. The Linux convention is to label all the network interfaces on a given machine in the sequence
eth0,eth1, and so on (although with some Linux versions and driver combinations, you also seewlan0,wlan1, and so on for wireless interfaces).On the BSDs, interfaces are assigned names that equal the driver name plus a sequence number. For example, older 3Com cards using the
epdriver appear asep0,ep1, and so on; Intel Gigabit cards are likely to end up asem0,em1, and so on. Some SMC cards are listed assn0,sn1, and so on. This system is quite logical, and makes it easier to find the documentation for the specifics of that interface. If your kernel reports (at boot time or inifconfigoutput) that you have an interface calledem0, you need only typeman emat a shell command-line prompt to find out what speeds it supports, whether there are any eccentricities to be aware of, whether any firmware download is needed, and so on.You should be aware that in BSDs, the configuration is /etc/rc.conf -centric. In general, the BSDs are organized to read the configuration from the file /etc/rc.conf, which is read by the /etc/rc script at startup. OpenBSD recommends using /etc/rc.conf.local for local customizations, since rc.conf contains the default values. FreeBSD uses /etc/defaults/rc.conf to store the default settings, making /etc/rc.conf the correct place to make changes. In addition, OpenBSD uses per-interface configuration files called hostname.<if>, where <if> is replaced with the interface name.
For the purpose of learning PF, you will need to concentrate on an /etc/pf.conf file, which will be largely your own creation.
If you need a broader and more thorough introduction to your BSD of choice, look up the operating system’s documentation, including FAQs and guides, at the project’s website. You can also find some suggestions for further reading in Appendix A.
This section is based on questions I’ve been asked via email or at meetings and conferences, as well as some that have popped up in mailing lists and other discussion forums. Some of the more common questions are covered here, in a FAQ-style[8] format.
In a word, no. Over the years, announcements have appeared on the PF mailing list from someone claiming to have started a Linux port of PF, but at the time of this writing, no one has yet claimed to have completed the task. The main reason for this is probably that PF is developed primarily as a deeply integrated part of the OpenBSD networking stack. Even after more than a decade of parallel development, the OpenBSD code still shares enough fundamentals with the other BSDs to make porting possible, but porting PF to a non-BSD system would require rewriting large chunks of PF itself, as well as whatever integration is needed at the target side.
For some basic orientation tips for Linux users to find their way in BSD network configurations, see Pointers for Linux Users in Pointers for Linux Users.
This book is mainly oriented toward users who edit their rule sets in their favorite text editor. The sample rule sets in this book are simple enough that you probably would not get a noticeable benefit from any of the visualization options the various GUI tools are known to offer.
A rather common claim is that the PF configuration files are generally readable enough that a graphic visualization tool is not really necessary. There are, however, several GUI tools available that can edit and/or generate PF configurations, including a complete, customized build of FreeBSD called pfSense (http://www.pfsense.org/), which includes a sophisticated GUI rule editor.
I recommend that you work through the parts of this book that apply to your situation, and then decide if you need to use a GUI tool to feel comfortable running and maintaining the systems you build.
The best strategy when converting network setups, including firewall setups, from one product to another is to go back to the specifications or policies for your network or firewall configuration, and then implement the policies using the new tool.
Other products will inevitably have a slightly different feature set, and the existing configuration you created for OtherProduct ® is likely to mirror slightly different approaches to specific problems, which do not map easily, or at all, to features in PF and related tools.
Having a documented policy, and taking care to update it as your needs change, will make your life easier. This documentation should contain a complete prose specification of what your setup is meant to achieve. (You might start out by putting comments in your configuration file to explain the purpose of your rules.) This makes it possible to verify whether the configuration you are running actually implements the design goals. In some corporate settings, there may even be a formal requirement for a written policy.
The impulse to look for a way to automate your conversion is quite understandable and perhaps expected in a system administrator. I urge you to resist the impulse and to perform your conversion after reevaluating your business and technical needs and (preferably) after creating or updating a formal specification or policy in the process.
Some of the GUI tools that serve as administration front ends claim the ability to output configuration files for several firewall products, and could conceivably be used as conversion tools. However, this has the effect of inserting another layer of abstraction between you and your rule set, and puts you at the mercy of the tool author’s understanding of how PF rule sets work. I recommend working through at least the relevant parts of this book before spending serious time on considering an automated conversion.
The world changed, and PF changed with it. More specifically, the OpenBSD developers have a very active and pragmatically critical relationship to their code, and like all parts of OpenBSD, the PF code is under constant review.
The lessons learned over almost a decade of PF development and use led to internal changes in the code that eventually made it clear to the developers that changing the syntax slightly would make sense. The result for you, the user, is that PF is now even easier to use and performs better than the earlier versions. If you are upgrading your system to OpenBSD 4.7 or newer, you are in for a real treat.
There are several good sources of information about PF and the systems on which it runs. You have already found one in this book. You can find references to a number of printed and online resources in Appendix A.
If you have a BSD system with PF installed, consult the online manual pages (man pages) for information about your exact release of the software. Unless otherwise indicated, the information in this book refers to the world as it looks from the command line on an OpenBSD 4.8 system.
[8] The three-letter abbreviation FAQ expands to either frequently asked questions or frequently answered questions—both equally valid.