The tests you’ve performed on your rule sets should have shown that PF was running and that your rules are behaving as expected. There are several ways to keep track of what happens in your running system. One of the more straightforward ways of extracting information about PF is to use the already familiar pfctl program.
Once PF is enabled and running, the system updates various counters and statistics in response to network activity. To confirm that PF is actually running and to view statistics about its activity, you can use pfctl -s, followed by the type of information you want to display. A pretty long list of information types is available (see man 8 pfctl and look for the -s options). We will be getting back to some of those display options in Chapter 8, and go into further detail about some of the statistics they provide in Chapter 9 when we use the data to optimize the configuration we are building.
The following shows an example of just the top part of the output of pfctl -s info (taken from my home gateway). The high-level information that indicates the system actually passes traffic can be found in this upper part.
$ sudo pfctl -s info
Status: Enabled for 24 days 12:11:27 Debug: err
Interface Stats for nfe0 IPv4 IPv6
Bytes In 43846385394 0
Bytes Out 20023639992 64
Packets In
Passed 49380289 0
Blocked 49530 0
Packets Out
Passed 45701100 1
Blocked 1034 0
State Table Total Rate
current entries 319
searches 178598618 84.3/s
inserts 4965347 2.3/s
removals 4965028 2.3/sThe first line of the pfctl output indicates that PF is enabled and has been running for a little more than three weeks, which is equal to the time since I last performed a system upgrade that required a reboot.
The Interface Stats part of the display shows the bytes in and out handled by the interface. The next few items are likely to be more interesting in our context, showing the number of packets blocked or passed in each direction. This is where we find an early indication of whether the filtering rules we wrote are catching any traffic. In this case, either the rule set matches expected traffic well or we have fairly well-behaved users and guests, with the number of packets passed overwhelmingly larger than the number of packets blocked in both directions.
The next important indicator of a working system that is processing traffic is the block of State Table statistics. The state table current entries line shows that there are 319 active states or connections, while the state table has been searched (searches) for matches to existing states on average a little more than 84 times per second, for a total of just over 178 million times since the counters were reset. The inserts and removals counters show the number of times states have been created and removed, respectively. As expected, the number of insertions and removals differs by the number of currently active states, and the rate counters show that for the time since the counters were last reset, the rate of states created and removed matches exactly, up to the resolution of this display.
The information here is roughly in line with the statistics you should expect to see on a gateway for a small network configured for IPv4 only. There is no reason to be alarmed by the packet passed in the IPv6 column. OpenBSD comes with IPv6 built in. During network interface configuration, by default, the TCP/IP stack sends IPv6 neighbor solicitation requests for the link local address. In a normal IPv4-only configuration, only the first few packets actually pass, and by the time the PF rule set from /etc/pf.conf is fully loaded, IPv6 packets are blocked by the block all default rule. (In this example, they do not show up in nfe0’s statistics because IPv6 is tunneled over a different interface.)