It is important to note that the presence of the log keyword only ensures that
the packet will be available to the ipfilter logging device; /dev/ipl. In order
to actually see this log information, one must be running the ipmon utility (or
some other utility that reads from /dev/ipl). The typical usage of log
is coupled with ipmon -s to log the information to syslog. As of ipfilter 3.3,
one can now even control the logging behavior of syslog by using log level
keywords, as in rules such as this:
block in log level auth.info quick on tun0 from 18.104.22.168/24 to any
block in log level auth.alert quick on tun0 proto tcp from any to 22.214.171.124/24 port = 21
In addition to this, you can tailor what information is being logged. For example, you may not be interested that someone attempted to probe your telnet port 500 times, but you are interested that they probed you once. You can use the log first keyword to only log the first example of a packet. Of course, the notion of "first-ness" only applies to packets in a specific session, and for the typical blocked packet, you will be hard pressed to encounter situations where this does what you expect. However, if used in conjunction with pass and keep state, this can be a valuable keyword for keeping tabs on traffic.
Another useful thing you can do with the logs is to keep track of interesting pieces of
the packet in addition to the header information normally being logged. Ipfilter will give
you the first 128 bytes of the packet if you use the log body keyword. You should
limit the use of body logging, as it makes your logs very verbose, but for certain
applications, it is often handy to be able to go back and take a look at the packet, or to
send this data to another application that can examine it further.