By now, you may be thinking that this setup gets awfully static and rigid. There will, after all, be some kinds of data relevant to filtering and redirection at a given time, but they do not deserve to be put into a configuration file! Quite right, and PF offers mechanisms for handling those situations.

Tables are one such feature. They are useful as lists of IP addresses that can be manipulated without reloading the entire rule set and also when fast lookups are desirable.

Table names are always enclosed in < >, like this:

table <clients> persist { 192.168.2.0/24, !192.168.2.5 }

Here, the network 192.168.2.0/24 is part of the table with one exception: The address 192.168.2.5 is excluded using the ! operator (logical NOT). The keyword persist makes sure the table itself will exist, even if no rules currently refer to it.

It is also possible to load tables from files where each item is on a separate line, such as the file /etc/clients:

192.168.2.0/24
!192.168.2.5

This, in turn, is used to initialize the table in /etc/pf.conf:

table <clients> persist file "/etc/clients"

So, for example, you can change one of our earlier rules to read like this to manage outgoing traffic from your client computers:

pass inet proto tcp from <clients> to any port $client_out

With this in hand, you can manipulate the table’s contents live, like this:

$ sudo pfctl -t clients -T add 192.168.1/16

Note that this changes the in-memory copy of the table only, meaning that the change will not survive a power failure or reboot, unless you arrange to store your changes.

You might opt to maintain the on-disk copy of the table using a cron job that dumps the table content to disk at regular intervals, using a command such as the following:

$ sudo pfctl -t clients -T show >/etc/clients

Alternatively, you could edit the /etc/clients file and replace the in-memory table contents with the file data:

$ sudo pfctl -t clients -T replace -f /etc/clients

For operations you will be performing frequently, sooner or later, you will end up writing shell scripts. It is likely that routine operations on tables such as inserting or removing items or replacing table contents will be part of your housekeeping scripts in the near future.

One common example is to enforce network access restrictions via cron jobs that replace the contents of the tables referenced as from addresses in the pass rules at specific times. In some networks, you may even need different access rules for different days of the week. The only real limitations lie in your own needs and your creativity.

We will be returning to some handy uses of tables frequently over the next chapters, and we will look at a few programs that interact with tables in useful ways.