> # First allow any outgoing tcp/udp packet and keep state of the connection
> # to also allow packets coming back from the connected host
> pass out quick on pppoe0 proto tcp/udp from any to any keep state keep frags
> 
> # Same thing for icmp
> pass out quick on pppoe0 proto icmp from any to any keep state
> 

There's a potential problem in the interaction of the two rules above
with the two below.

> 
> # block all other incoming traffic and return rst/port-unr packets;
> # log only errors and warnings
> block return-rst in log level auth.alert quick on pppoe0 proto tcp \
>  from any to any
> block return-icmp(port-unr) in log level auth.alert quick on pppoe0 \
>  proto udp from any to any
> 

Suppose a remote host attempts to initiate a connection to a blocked
port.  His SYN packet causes an RST to be sent back.  Because of your
"pass out ... proto tcp ... keep state ..." rule, that RST creates a
state.  The remote host then sends the exact same SYN packet back,
and, because of the state in your packet filter, it gets through. 
I haven't seen this happen with IP Filter, but I have seen it with
other packet-filtering software.  It's probably wise to err on the
side of caution, and replace

	pass out quick on pppoe0 proto tcp/udp from any to any keep state keep frags

with something like

	pass out quick on pppoe0 proto tcp from any to any flags S keep state keep frags
	pass out quick on pppoe0 proto udp from any to any keep state keep frags

and maybe add a

	pass out quick on pppoe0 proto icmp from any to any icmp-type unreach

before

	pass out quick on pppoe0 proto icmp from any to any keep state

Actually, I think that the only ICMP-type you "need" to keep state on is
'echo', for 'traceroute' to work properly.

Also, you're returning RSTs for any denied TCP packet, not just SYN packets
addressed to your host.  While there's probably no harm in that, I don't
think it's necessary.  (If I'm wrong here, I'm sure someone will correct
me ...)

David S.