On 2006/08/26 21:57, matthew.garman@gmail.com wrote:
> For some reason, I'm not "getting it" when it comes to pf... Two
> things I can't figure out: (1) filtered vs blocked for some TCP
> ports and (2) rules for tun0, my vpn interface.

You didn't mention the OS version; if I can assume you're running
an up-to-date OS then you have followed some out-of-date sample
configuration: you're using `pass on lo0' rather than the favoured
`set skip on lo', and the setup for proxying FTP sessions is for
the old /usr/libexec/ftp-proxy, not 3.9's /usr/sbin/ftp-proxy.
Both these increase efficiency (the new ftp-proxy only handles
control connections itself; it generates a NAT rule for the data
connection so the actual transfer is handled straight in the NAT
and routing code in the kernel - this is vastly more efficient
than punting ftp data packets to a userland proxy and back again).

I think you're more likely to `get it' by looking at (maybe
printing a copy) of pf.conf(5) manual page, and writing your own
file based on the default /etc/pf.conf (or from scratch) rather
than following a non-OpenBSD.org guide. (I know there are plenty
of guides out there, and most of them will get you a functioning
system, but it sounds like you might actually want to understand
what you're doing and the howto-style guides aren't great for
that).

> ext_if = "vr0"

Point of style - interface groups are nice in place of macros
for interface names; if you add a CARP partner using different
interface names you can still use the same pf.conf, and I think
the firewall ruleset is a little easier to read when there are
fewer $ involved.

Also good if you have interfaces that don't exist when the
ruleset is loaded but are brought up later (maybe you want to
add tun interfaces while the firewall is running - you can
just "pass on tun" and it will apply to all present and
future tunX interfaces without adjusting rules).

You can use `egress' in place of `$ext_if' in interfaces names
(e.g. `pass on egress') - this group automatically contains any
interface holding a default route (and you can add other
interfaces to the group if you have a more complex routing
setup or if you don't use a default route <bgpd users mainly>).

> tcp_services = "{ 22 }"
> udp_services = "{ 1194 }"

These macros don't save any time, and keep you from looking at
the actual ruleset when you're editing rules - opinions vary but
I prefer to list the ports by number (or name, from /etc/services)
in the main rule section.

> pass out log on $ext_if proto tcp all modulate state flags S/SA
> pass out log on $ext_if proto { udp, icmp } all keep state

You can combine these into a single rule,
`pass out log on $ext_if modulate state flags S/SA' -
PF will just use the applicable parts (mod state S/SA for tcp,
keep state for others).

> So, if I do a "tcpdump -n -e -ttt -i pflog0"

Good, you found this - this is very useful for finding where the
ruleset is broken. You can add filters at the end too, which is good
on a busy system e.g.

# tcpdump -nettti pflog0 icmp
# tcpdump -nettti pflog0 host 10.20.30.40 and port https

> while trying to ping the obsd box from the vpn client, I see this:
>
> Aug 26 21:08:49.371324 rule 4/(match) block in on tun0: \
> 192.168.2.6 > 192.168.2.1: icmp: echo request (DF)
>
> How can I tell which rule is "rule 4"?

# pfctl -sr -vv