As Henning reviews the Absolute OpenBSD manuscript, he’s pointed out items that I’ve missed. Some of these are only documented in man pages, while others don’t seem to really be documented anywhere except in the source code. Here’s an interesting tidbit he pointed out that I haven’t seen anywhere other than Henning’s email. (Having said this in public, I’ll now find all sorts of examples that I missed, such as Henning’s slides from EuroBSDcon 2010.)
You can log specific connections to separate log devices, for simpler debugging. You need the log rule near the beginning of your ruleset, but it doesn’t have an effect on whether a packet is passed or blocked, or how it’s translated. Here’s a pf.conf line to tell PF to watch for connections from 192.0.2.226 to 203.0.113.34.
match log (matches) from 192.0.2.226 to 203.0.113.34
Now watch the log interface, searching for the destination address:
# tcpdump -n -e -ttt -i pflog0 ip host 203.0.113.34
tcpdump: WARNING: snaplen raised from 116 to 160
tcpdump: listening on pflog0, link-type PFLOG
Dec 17 17:40:25.071592 rule 2/(match) block out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384
Dec 17 17:40:25.071600 rule 5/(match) pass out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384
Dec 17 17:40:25.071604 rule 5/(match) pass out on fxp0: 192.0.2.226.14033 > 203.0.113.34.822: S 2830367545:2830367545(0) win 16384
^C
You get the number of every rule that matches the packet. If you use NAT, it prints original and destination addresses. With my wussy PF rules, this isn’t terribly exciting. With more complicated rules, however, it makes debugging rulesets much easier.
This is the sort of useful information you’ll get if you preorder the new Absolute OpenBSD. (See how I subtly slipped that in? I’m getting good at this marketing stuff.)