I can't think of where I've seen a site that gives details (the best place
to look would probably be packet-filter how-tos) but here is a quick
The normal 'block' option just drops a packet. The packet sender
has no idea what happened to the packet, because it received no
response. Thus it will sit and wait for a timeout, and thus might
resend a few times before giving up. For a TCP packet 'block
return-rst' means the firewall will send a response back to the packet
originator in essence telling it that its request for a connection
just isn't going to happen (i.e. don't waste your time waiting around).
If you are keeping state on inbound connections, and using the
'flags S/SA' option, than I can't see that you should have to worry
about abuse from incoming tcp-resets. (Outgoing can be another
matter though -- As I recall for some sneaky half-open port scans,
any kind of response such as a tcp-reset may give all the information
the person probing is looking for, but rumour has it pf's authors
know more about these tricks than we mere mortals, and take them into
The 'block return-icmp' is similar, but is also suited to icmp/udp
type packets. Sometimes you don't want to just drop the packet
without sending a response, particularly in the case of any outbound
connections that you are blocking. (For example it can be annoying
to have your web-browser waiting around for a connection it isn't
going to get because the reponse is blocked at firewall and can't
Both types of packets have some potential to be abused for port-scans,
finger-prints and/or DoS attacks -- I don't remember all the details.
Note that there are numerous 'types' of ICMP packets, with varying
potential for abuse. Not letting the 'destination unreachable' type
of ICMP packet above through your firewall usually isn't worth it
(abuse is very unlikely).
This probably isn't as much detail as you would like, but for a
firewall it is all you really need to know. In essense, use the
'return' option if you don't want a packet sender to wait around
or keep trying to send to something you have blocked. And don't go out
of your way to block all 'unreachable' type ICMP packets, it isn't worth
the performance hit (actually I think Pf's state keeping functionality
handles these things intelligently anyway ... someone correct me if I'm
I hope this helps...
> I am tyring to build a nice pf.conf and I often see references to
> return-rst and return-icmp.
> The pf.conf man page mentions them but doesn't explain them. RFC for
> icmp doesn't mention them, explicitly anyway.
> Can someone direct me to some intelligible source that explains these
> things and why they are often blocked via firewalls. I have an idea
> but my policy is to be as complete in my understanding as possible.