Options

Basic settings that affect how PF performs basic actions, such as "how long does PF keep state on a TCP connection in the SYN+ACK state" and "do we have logging on?" are classified as options. All option rules start with the "set" keyword.

Timing Options

You can exhaustively tweak the global timeouts for stateful inspection on TCP, UDP, and other protocols. For most users, this is just a complicated way to get a truly impressive migraine. Adjusting TCP timeouts is a very tricky subject, and it generally causes network administrators more problems than it solves. Timeouts are all interrelated, and adjusting one without adjusting the others will not achieve your desired results unless you know exactly what you're doing and why. Similarly, PF's defaults for other protocols are almost certainly correct for the standard Internet.

Problems certainly do happen when you're not running on the standard Internet, however. You might be behind an overloaded link, or perhaps you have a satellite connection between you and the rest of the world. PF includes a set of precalculated network timing options for particular sorts of networks. You can set these with the optimization keyword. OpenBSD supports four different sorts of timing optimization: normal, high-latency, aggressive, and conservative.

The normal setting is for use on a system connected to the Internet via a modem, cable modem, T1, OC192, or other fairly standard method. If you don't specify an optimization, this is the default — in fact, "default" is an alias for "normal."

The high-latency optimization option is for systems connected to the Internet via satellite or other extremely slow methods. Timeouts are turned up very high. "Satellite" is an alias for "high-latency."

Aggressive optimization quickly discards idle connection information. This saves memory and CPU time, at the possible expense of cutting off legitimate connections. If you are on a high-speed network and have limited memory on your system, or you don't want people leaving idle connections hanging around to systems on the other side of the firewall, you might want to use aggressive optimization.

Conservative optimization extends timeouts coherently so as to not cut off any legitimate connections if at all possible. This can use more CPU time and memory.

Setting the optimization is very easy:

 set optimization high-latency 

If you're a real TCP/IP stud, feel free to look at pf.conf(5) for the "set timeout" keyword, and adjust the timeout on each individual stage of the protocol negotiation process as you see fit.

Enabling Logging

PF's logging functions can be enabled on an interface-by-interface basis with the "loginterface" keyword. Each interface that you want to enable logging on should be specified by this option:

 set loginterface fxp0 

You can disable logging entirely, on any interface, by setting the interface name to "none."

PF Memory Limits

One problem with filtering network traffic is that you may have very little control over how much traffic you receive. One day Slashdot might post a link to a web page behind your OpenBSD firewall, and you would start to receive tens of thousands of connections per minute. OpenBSD can handle this, if you have the proper hardware, but it may consume all your system memory if your hardware is inadequate. The two features that are most likely to use memory are stateful inspection and fragment reassembly. By limiting the amount of memory you will allocate to these, you can guarantee that your system will have memory left for such trivial things as a command prompt. The "set limits" keyword configures these limits. You can limit the number of connections you are performing stateful inspection on by using "set limits states" and limit the number of fragments with "set limit frags":

 set limit states 5000 set limit frags 10000 

To make your rules slightly shorter, you can set both of these on a single line using braces.

 set limit { states 5000, frags 10000 } 

Yes, you can use queuing to limit outbound traffic, but that won't help you if your system runs out of memory.

Generally, speaking, one state uses about 1KB of memory, so a machine with 64MB RAM could handle about 65,000 states. The amount of memory used by fragments depends on the size of the fragments, but is generally quite small.

Blocked Packet Policy

When PF blocks packets, it can either send back an error message to the originating system or refuse the traffic without returning any errors. Configure this with the "set block-policy" keyword.

It is generally considered polite to return an error, as clients will immediately realize that they cannot make this connection and (usually) tell the user that the connection has been refused. Your security policy may or may not involve politeness. The "return" option tells PF to return polite errors: an RST for TCP connections and an ICMP unreachable message for UDP connections. All other connections will be silently dropped anyway, but this covers most situations:

 set block-policy return 

By default PF silently drops blocked packets. If your silently drops the traffic, applications will have to wait for the network protocol timeout to elapse before realizing that they cannot connect. The "drop" option tells PF to silently drop packets:

 set block-policy drop 

This blocked packet policy can be overridden on individual filter statements.