pf feature request -- easier troubleshooting/debugging.

[Sherwood Botsford]

Runing OpenBSD 3.7 Generic kernel.

I'm a relative newby to pf, and am still wrapping my tiny brain around
it's syntax.

Biggest problem with pf is figuring out:
A:  Is it blocking what you expect?
B:  Why is it not passing what thought it would?

The pf/modified tcpdump is a slick solution for not having to grovel
through a billion lines of log.

However I find that matching the rule number that tcpdump gives is hard
to match with the rules in the pf.conf.

After playing a bit, I tried
pfctl -s rules | cat -n
to get a numbered rule set.
This sort of works, except that is seems to be offset.

It also means that I'm matching back and forth for a fairly long list.

Would it be possible to hack pf so that the rule numbers thrown to
tcpdump were 'double numbered'  e.g.  Suppose that the following rule is
  line #60 in pf.conf

pass in quick on $lan proto {tcp, udp} from any to any port $p_allowed

This expands to 16 rules.
If these were numbered 60.001 through 60.016  it would be a lot easier
to figure out what is going on.

Secondly, I wish:
pfctl -s rules
would number them without running through cat -n

Thirdly, I wish I could do something like:
pfctl --trace 1.2.3.5
and see what the rule processing is doing.
(By default --trace would enable the tracing for N packets then exit.)

So the output would look something like
trace 1.2.3.5 rule 60.1 pass
trace 1.2.3.5 rule 61.11 block
trace 1.2.3.5 rule 75.1 pass

Aha! line 75 is letting it out.

This, to me, would be easier that cluttering up the pf.conf file with a
raft of log statements.

(verbose trace -- it prints out the rule too?)
(tags -- print out tag changes)

--
Sherwood Botsford [hidden email]
St. John's School of Alberta 780-848-2881 Ext 134
RR - 5, Stony Plain, Alberta, T7Z 1X5

[Otto Moerbeek]

On Thu, 23 Feb 2006, sbotsford wrote:

> Runing OpenBSD 3.7 Generic kernel.
>
> I'm a relative newby to pf, and am still wrapping my tiny brain around it's
> syntax.
>
> Biggest problem with pf is figuring out:
> A:  Is it blocking what you expect?
> B:  Why is it not passing what thought it would?
>
> The pf/modified tcpdump is a slick solution for not having to grovel through a
> billion lines of log.
>
> However I find that matching the rule number that tcpdump gives is hard to
> match with the rules in the pf.conf.

Check the man page of pfctl. It's easy to get the rule numbers.

> After playing a bit, I tried
> pfctl -s rules | cat -n
> to get a numbered rule set.
> This sort of works, except that is seems to be offset.
>
> It also means that I'm matching back and forth for a fairly long list.
>
> Would it be possible to hack pf so that the rule numbers thrown to tcpdump
> were 'double numbered'  e.g.  Suppose that the following rule is  line #60 in
> pf.conf
>
> pass in quick on $lan proto {tcp, udp} from any to any port $p_allowed
>
> This expands to 16 rules.
> If these were numbered 60.001 through 60.016  it would be a lot easier to
> figure out what is going on.
>
> Secondly, I wish:
> pfctl -s rules
> would number them without running through cat -n
>
> Thirdly, I wish I could do something like:
> pfctl --trace 1.2.3.5
> and see what the rule processing is doing.
> (By default --trace would enable the tracing for N packets then exit.)
>
> So the output would look something like
> trace 1.2.3.5 rule 60.1 pass
> trace 1.2.3.5 rule 61.11 block
> trace 1.2.3.5 rule 75.1 pass
>
> Aha! line 75 is letting it out.

This is a silly idea. Rules do not work on ip address alone. Apart
from tcp flags, port numbers, other protocols pf is a statefull packet
filter.

        -Otto

PS: this is not a bug report, wrong list.

>
> This, to me, would be easier that cluttering up the pf.conf file with a raft
> of log statements.
>
> (verbose trace -- it prints out the rule too?)
> (tags -- print out tag changes)
>
> --
> Sherwood Botsford [hidden email]
> St. John's School of Alberta 780-848-2881 Ext 134
> RR - 5, Stony Plain, Alberta, T7Z 1X5