Logging PF
Tell PF to log packets with the log keyword in a rule.
pass out log on egress from lan:network to any
Without additional setup, however, those logs just go to the PF log device pflog0. To successfully log PF messages, you must run the packet filter logger pflogd(8). If you start PF at boot, pflogd is automatically started with it. Otherwise, you must start it on the command line.
One thing to remember is that if you’re using stateful inspection, only the first packet that triggers a rule is logged. Other packets that are part of the same state are not logged. To log all packets in a stateful connection, give the all modifier to the log keyword, but beware because this can generate very large logs.
pass out log (all) on egress from lan:network to any
Logging is especially useful when troubleshooting connection problems. If packets are being blocked when you think they should be passed, add logging to your block statements to see which rule is stopping the traffic.
I don’t recommend logging everything, especially because logs can grow quite large. Log selectively. For example, perhaps you don’t care which websites your local users visit, but do want to know about incoming traffic. And be sure to exclude your firewall logging traffic from your packet filter logs, or you’ll quickly find that PF is logging the transmission of the logs of the log transmissions, which are logs of transmitting the logs, from when you transmitted the logs … yadda yadda yadda.
Reading PF Logs
PF logs in the tcpdump(8) binary format. Use tcpdump to examine the data. To just dump everything in the log, tell tcpdump to read the log file.
# tcpdump -r /var/log/pflog
This can generate a huge amount of output. See Filtering tcpdump for some hints.
Real-Time Log Access
The entries in /var/log/pflog are not added in real time; pflogd(8) buffers its records until writing a log message is worthwhile. To see PF logs in real time, attach tcpdump to the pflog0 interface with the -i flag.
# tcpdump -i pflog0
Depending on how much traffic you’re logging, this might also produce an overwhelming amount of information. You must filter tcpdump to make it useful. Or if you pretend you missed my earlier warning about log sizes, you can devise a one-liner that uses logger to send your PF logs as text to syslog.
Filtering tcpdump
Every system administrator should know how to use tcpdump. Here’s your motivation for doing so.
When troubleshooting a problem with a particular connection, you probably don’t care about every packet passing through the filter. You care about traffic to or from a particular host. Specify an IP address with the ip or ip6 expression.
# tcpdump -i pflog0 ip host 192.0.2.2
This will display only traffic to and from this particular host.
To narrow things further and see only the traffic between two hosts, combine the hosts with the and keyword.
# tcpdump -i pflog0 ip host 192.0.2.2 and ip host 203.0.113.88
Maybe you’re interested in only a specific port, on a specific address. Use the tcp or udp keyword and the port number to filter on that.
# tcpdump -i pflog0 ip host 139.171.199.254 and tcp port 80
Read the tcpdump(8) man page for an exhaustive list of innumerable other filtering options.
If using tcpdump doesn’t appeal to you, consider the pflow(4) NetFlow exporter. Network flow is a complicated topic, but the book Network Flow Analysis (No Starch Press, 2010) might help you.
Ruleset Tracing
Sometimes, knowing whether a packet passed or failed isn’t enough. You know that a packet was blocked, but not why. You want to watch the packet pass through the rules and see which rules affect it.
Suppose an internal host 192.0.2.226 cannot connect to the external host 203.0.113.34. The log would show that the packet is blocked, but not why. You can specifically have PF log matching rules. Add a line like this to the top of your pf.conf file:
match log (matches) from 192.0.2.226 to 203.0.113.34
This is a standard packet-filtering rule. You could use an individual IP address, a port number, or any other legal packet filter terms. Reload your packet-filtering rules.
Turn on tcpdump, and filter based on one of the IP addresses in your match statement. If you’re using NAT, filter on the IP address that doesn’t change.
# tcpdump -n -e -ttt -i pflog0 ip host 203.0.113.34 Dec 17 18:05:07.773703 rule 0/(match) match out on fxp0: 192.0.2.226.24916 > 203.0.113.34.22: S 1730871963:1730871963(0) win 16384 <mss 1460,nop,nop, sackOK,nop,wscale 3,nop,nop,timestamp 597858150[|tcp]> (DF) Dec 17 18:05:07.773708 rule 2/(match) block out on fxp0: 192.0.2.226.24916 > 203.0.113.34.22: S 1730871963:1730871963(0) win 16384 <mss 1460,nop,nop, sackOK,nop,wscale 3,nop,nop,timestamp 597858150[|tcp]> (DF) Dec 17 18:05:07.773712 rule 5/(match) pass out on fxp0: 192.0.2.226.24916 > 203.0.113.34.22: S 1730871963:1730871963(0) win 16384 <mss 1460,nop,nop, sackOK,nop,wscale 3,nop,nop,timestamp 597858150[|tcp]> (DF)
While I won’t go through all the annoying details of reading tcpdump output, you can see that PF logs the rule numbers that this data connection matches, and whether the rule passes or blocks the connection. If the connection involves NAT, you’ll see the actual and translated IP addresses.
At this point, you know enough about PF to protect a small network. If you need more, definitely check out The Book of PF, 2nd edition (No Starch Press, 2010).
Now let’s look at some of the more exotic edges of OpenBSD.
[48] Can Lucas configure a highly available firewall cluster in a day? Yep. Can he search and replace IP addresses in a text file without screwing everything up? Nope.