The obvious question becomes, “If ICMP is such a good and useful thing, shouldn’t we let it all through, all the time?” The answer is that it depends.

Letting diagnostic traffic pass unconditionally makes debugging easier, of course, but it also makes it relatively easy for others to extract information about your network. So, a rule like the following might not be optimal if you want to cloak the internal workings of your network:

pass inet proto icmp

In all fairness, it should also be said that you might find some ICMP traffic quite harmlessly riding piggyback on your keep state rules.

The easiest solution could very well be to allow all ICMP traffic from your local network through, and let probes from elsewhere stop at your gateway:

pass inet proto icmp icmp-type $icmp_types from $localnet
pass inet proto icmp icmp-type $icmp_types to $ext_if

Stopping probes at the gateway might be an attractive option anyway, but let’s look at a few other options that will demonstrate some of PF’s flexibility.

The rule set we have developed so far has one clear disadvantage: Common troubleshooting commands such as ping and traceroute will not work. That may not matter too much to your users, and since it was the ping command that scared people into filtering or blocking ICMP traffic in the first place, there are apparently some people who feel we are better off without it. However, if you are in my perceived target audience, you will be rather fond of having those troubleshooting tools available. And with a couple of small additions to the rule set, they will be.

ping uses ICMP, and in order to keep our rule set tidy, we start by defining another macro:

icmp_types = "echoreq"

Then we add a rule that uses the definition:

pass inet proto icmp icmp-type $icmp_types

If you need more or other types of ICMP packets to go through, you can expand icmp_types to a list of those packet types you want to allow.

traceroute is another command that is quite useful when your users claim that the Internet isn’t working. By default, Unix traceroute uses UDP connections according to a set formula based on destination. The following rule works with the traceroute command on all forms of Unix I’ve had access to, including GNU/Linux:

# allow out the default range for traceroute(8):
# "base+nhops*nqueries-1" (33434+64*3-1)
pass out on $ext_if inet proto udp to port 33433 >< 33626

This gives you a first taste of what port ranges look like. They are quite useful in some contexts.

Experience so far indicates that traceroute implementations on other operating systems work roughly the same. One notable exception is Microsoft Windows. On that platform, the tracert.exe program uses ICMP echo requests for this purpose. So if you want to let Windows traceroutes through, you need only the first rule, much like letting ping through. The Unix traceroute program can be instructed to use other protocols as well, and will behave remarkably like its Microsoft counterpart if you use its -I command-line option. You can check the traceroute man page (or its source code, for that matter) for all the details.

This solution is based on a sample rule I found in an openbsd-misc post. I’ve found that list, and the searchable list archives (accessible among other places from http://marc.info/), to be a very valuable resource whenever you need OpenBSD or PF-related information.

The last bit I will remind you about when it comes to troubleshooting is the path MTU discovery. Internet protocols are designed to be device-independent, and one consequence of device independence is that you cannot always predict reliably what the optimal packet size is for a given connection. The main constraint on your packet size is called the maximum transmission unit, or MTU, which sets the upper limit on the packet size for an interface. The ifconfig command will show you the MTU for your network interfaces.

Modern TCP/IP implementations expect to be able to determine the correct packet size for a connection through a process that simply involves sending packets of varying sizes within the MTU of the local link with the “do not fragment” flag set. If a packet then exceeds the MTU somewhere along the way to the destination, the host with the lower MTU will return an ICMP packet indicating “type 3, code 4,” when the local upper limit has been reached. Now, you don’t need to dive for the RFCs right away. Type 3 means destination unreachable, and code 4 is short for fragmentation needed, but the do not fragment flag is set. So if your connections to other networks, which may have MTUs that differ from your own, seem suboptimal, you could try changing your list of ICMP types slightly to let the destination-unreachable packets through:

icmp_types = "{ echoreq, unreach }"

As you can see, this means you do not need to change the pass rule itself:

pass inet proto icmp icmp-type $icmp_types

Now I’ll let you in on a little secret: In almost all cases, these rules are not necessary for purposes of path MTU discovery (but they don’t hurt either). However, even though the default PF keep state behavior takes care of most of the ICMP traffic you will need, PF does let you filter on all variations of ICMP types and codes. If you want to delve into more detail, the list of possible types and codes are documented in the icmp(4) and icmp6(4) man pages. The background information is available in the RFCs.^[18]