Doug Hardie wrote:
On 22 January 2010, at 01:45, Erik Norgaard wrote:
To debug pf rules:
- always add direction to the rule, pass or block, add interface to all
rules except default policy, keep state on all pass rules
- group your rules per direction, then per interface
- add log to all rules and watch pflog to see which rule blocks or
passes traffic.
- use keyword quick for any decisive rule
- check the parsing of your ruleset, pfctl -sr
then come back and ask for help.
Where do you find the rule information in the pflog output from tcpdump?
a snip:
alpha# tcpdump -n -e -i pflog0
tcpdump: WARNING: pflog0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size
96 bytes
11:55:20.910140 rule 81/0(match): block in on vr1: 172.16.1.127.52444 >
172.16.0.1.23: tcp 44 [bad hdr length 0 - too short, < 20]
rule 81 blocks. Now, problem is that your rules may be more compact,
you'll find the rule with pfctl -sr. Now admittedly, I got:
pass in quick on vr1 inet proto udp from 172.16.0.0/23 to <local_ip>
port = secret_service keep state
ofcourse, that rule didn't block. But two lines down I found:
block return in log quick on vr1 inet from 172.16.0.0/23 to <local_ip>
This makes sence, so why the offset 2? The first line of the output from
pfctl -sr is
scrub all fragment reassemble
that shouldn't count as a rule. And then, if pflog starts counting with
0 while vi counts from 1 that explains it.
Yet another reason to check the rules as parsed using pfctl -sr.
Anyway, not trying to cut corners is the first step, then add log so you
can see whats going on, use quick to avoid some packet fall through and
being matched by a different rule than intended, organizes your rules so
you can easily separate things out.
My rules are grouped together like this:
# default policy
block all
block in log <general condition>
pass in quick some packets keep state
block in log quick <general condition>
block out log <general condition>
pass out quick some packets keep state
block out log quick <general condition>
# Default policy catch all should never apply
block log all
the conditions for the pass rules should match those of the first block
and then be more specific, say, only apply to one port. Doing so, the pf
rule parser will optimize the ruleset.
Even if I know that a given rule can only match packets on the vr0
interface, I explicitly state the interface. It makes it clear what's
going on.
Once the ruleset is debugged and working you can remove the log statements.
BR, Erik
--
Erik Nørgaard
Ph: +34.666334818/+34.915211157 http://www.locolomo.org
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"