When your configuration does not behave as expected, there may be an error in the rule set logic, so you need to find the error and correct it. Tracking down logic errors in your rule set can be time-consuming, and could involve manually evaluating your rule set, both as it is stored in the pf.conf file and the loaded version after macro expansions and any optimizations.

Users often initially blame PF for problems that turn out to be basic network problems. Network interfaces set to wrong duplex settings, bad netmasks, and faulty network hardware are common culprits.

Before diving into the rule set itself, you can easily determine whether the PF configuration is causing the problem. To do so, disable PF with pfctl -d to see if the problem disappears. If the problem persists when PF is disabled, you should turn to debugging other parts of your network configuration instead. On the other hand, if the problem disappeared upon disabling PF, and you are about to start adjusting your PF configuration, make sure that PF is enabled and that your rule set is loaded, with this command:

$ sudo pfctl -si | grep Status
Status: Enabled for 20 days 06:28:24            Debug: err

Status: Enabled tells us that PF is enabled, so we try viewing the loaded rules with a different pfctl command:

$ sudo pfctl -sr
match in all scrub (no-df max-mss 1440)

block return log all
block return log quick from <bruteforce> to any
anchor "ftp-proxy/*" all

Here, pfctl -sr is equivalent to pfctl -s rules. The actual output is likely to be a bit longer than shown here, but this is a good example of what you should expect to see when a rule set is loaded.

For debugging purposes, consider adding the -vv flag to the pfctl command line to see rule numbers and some additional debug information, like this:

$ sudo pfctl -vvsr
@0 match in all scrub (no-df max-mss 1440)
  [ Evaluations: 341770    Packets: 3417668   Bytes: 2112276585  States: 125   ]
  [ Inserted: uid 0 pid 14717 State Creations: 92254 ]
@1 match out on nfe0 inet from 10.0.0.0/8 to any queue(q_def, q_pri) nat-to
(nfe0:1) round-robin static-port
  [ Evaluations: 341770    Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: uid 0 pid 14717 State Creations: 0     ]
@2 match out on nfe0 inet from 192.168.103.0/24 to any queue(q_def, q_pri) nat-to
(nfe0:1) round-robin static-port
  [ Evaluations: 68623     Packets: 2138128   Bytes: 1431276138  States: 103   ]
  [ Inserted: uid 0 pid 14717 State Creations: 39109 ]
@3 block return log all
  [ Evaluations: 341770    Packets: 114929    Bytes: 62705138    States: 0     ]
  [ Inserted: uid 0 pid 14717 State Creations: 0     ]
@4 block return log (all) quick from <bruteforce:0> to any
  [ Evaluations: 341770    Packets: 2         Bytes: 104         States: 0     ]
  [ Inserted: uid 0 pid 14717 State Creations: 0     ]
@5 anchor "ftp-proxy/*" all
  [ Evaluations: 341768    Packets: 319954    Bytes: 263432399   States: 0     ]
  [ Inserted: uid 0 pid 14717 State Creations: 70    ]

Now you should perform a structured walk-through of the loaded rule set. Find the rules that match the packets you are investigating. What is the last matching rule? If more than one rule matches, is one of the matching rules a quick rule? (As you probably recall from earlier chapters, when a packet matches a quick rule, evaluation stops, and whatever the quick rule specifies is what happens to the packet.) If so, you will need to trace the evaluation until you hit the end of the rule set or the packet matches a quick rule, which then ends the process. If your rule set walk-through ends somewhere other than the rule you were expecting to match your packet, you have found your logic error.

Rule set logic errors tend to fall into three types:

Chapter 8 introduced tcpdump as a valuable tool for reading and interpreting PF logs. The program is also very well suited for viewing the traffic that passes on a specific interface. What you learned about PF’s logs and how to use tcpdump’s filtering features will come in handy when you want to track down exactly which packets reach which interface.

Here is an example of using tcpdump to watch for TCP traffic on the xl0 interface (but not showing SSH or SMTP traffic) and print the result in very verbose mode (vvv):

$ sudo tcpdump -nvvvpi xl0 tcp and not port ssh and not port smtp
tcpdump: listening on xl0, link-type EN10MB
21:41:42.395178 194.54.107.19.22418 > 137.217.190.41.80: S [tcp sum ok]
3304153886:3304153886(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale
0,nop,nop,timestamp 1308370594 0> (DF) (ttl 63, id 30934, len 64)
21:41:42.424368 137.217.190.41.80 > 194.54.107.19.22418: S [tcp sum ok]
1753576798:1753576798(0) ack 3304153887 win 5792 <mss 1460,sackOK,timestamp
168899231 1308370594,nop,wscale 9> (DF) (ttl 53, id 0, len 60)

The connection shown here is a successful connection to a website.

There are more interesting things to look for, though, such as connections that fail when they should not according to your specifications, or connections that succeed when your specification says they clearly should not.

The test in these cases involves tracking the packets’ path through your configuration. Once more, it is useful to check to see if PF is enabled or if disabling PF makes a difference. Building on the result from that initial test, you then perform the same kind of analysis of the rule set as described previously:

The main outline for the test procedure is fairly fixed. If you have narrowed down the cause to your PF configuration, again it’s a case of finding out which rules match and which rule ends up determining whether the packet passes or is blocked.