Use the packet filter control program pfctl(8) to manage, configure, and extract information from PF. You can see the current packet filter rules and settings, connections being processed, the state of the TCP/IP transactions, debugging information, and all kinds of other details. You can also parse rules files and install them in the actual packet filter.

You’ll see many different options for pfctl, addressing every aspect of packet-filter management. Many of these are rather lengthy, but you need to type only as much of the word arguments to make a command unique. For example, instead of typing pfctl -s rules, you can get away with pfctl -sr because no other argument to pfctl -s begins with an r. That said, I give all examples in their full form, as it’s impossible to guarantee that OpenBSD won’t add some other argument that begins with r in the future.

I focus on using pfctl for viewing PF output, but OpenBSD also includes PF views in systat(1). For a dynamic display of PF activity, somewhat like top(1) for the network, look at systat. Run systat by giving the name of the view as an argument, such as systat pf. And, as always, any time you want more detail from pfctl, add one or two -v arguments for verbose mode.

You configure PF in /etc/pf.conf. The pf.conf file contains statements and rules, whose format varies with the features they configure. You’ll be very good friends with this file before we’re through.

OpenBSD lets you put interfaces in named groups, which you can refer to in PF rules. This abstracts away the actual physical interface, and lets you build policy-based rulesets. Take a look at this interface:

# ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
…
        groups: egress
…

This interface is in the egress group. An interface is assigned to the egress group if a default route is reached over it.

To move this interface to a new group, dmz, remove it from the egress group and add it to the dmz group. An interface group is created when you assign the first interface to it, and one interface can be in any number of groups.

# ifconfig em0 -group egress
# ifconfig em0 group dmz
# ifconfig em0
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
…
        groups: dmz
…

You can now write rules that reference interface groups instead of specific interfaces.

Let’s dismantle the default pf.conf from an OpenBSD system and identify some parts. Many of the default entries are commented out, but identifying them will help you understand how the components fit together.

It begins with an option:

set skip on lo

Options turn features on and off, or set general rules on how other features behave. The skip option disables PF on a per-interface basis.

Next comes the anchor setting:

anchor "ftp-proxy/*",

An anchor is a set of dynamic sub-rules for packet filtering. If a packet hits an anchor as it’s processed through the filter rules, it’s dropped into this sub-ruleset for further processing. pfctl can change the rules running in the kernel, and an anchor is a way of saying, “Add new rules here.”

Anchors are generally used for letting outside software add rules to the firewall. For example, FTP is a complicated protocol that requires all sorts of firewall rules. OpenBSD includes an FTP proxy that dynamically adds the necessary rules for permitted FTP connections.

Then come two packet-filtering rules:

pass in quick inet proto tcp to port ftp divert-to 127.0.0.1 port 8021
pass

The first is a rule to support FTP traffic, in combination with the FTP anchor. We’ll look at anchors and FTP handling in more detail in the next chapter. The other is a much simpler packet-filtering rule, which permits all traffic.

Up next are two tables, which are lists of IP addresses:

table <spamd-white> persist
table <nospamd> persist file "/etc/mail/nospamd"

External programs can dynamically alter tables, and you can add addresses to tables directly within pf.conf or in an external file. These two tables are used by the antispam software spamd(8).

After the tables is another packet-filtering rule:

pass in on egress proto tcp from any port smtp 
    rdr-to 127.0.0.1 port spamd

This rule is interesting in that it refers to an interface group. Traffic is permitted in, as long as it arrives on an interface in the egress group.

And the final rule is as follows:

block in on ! lo0 proto tcp to port 6000:6010

This packet-filtering rule stops traffic. If a packet arrives on any interface except the loopback interface, and the packet is a TCP protocol going to port 6000 through 6010 inclusive, it is blocked.

This is the sort of thing you’ll see in pf.conf. Let’s dive into some specifics of filtering rules.