From owner-freebsd-questions@FreeBSD.ORG Fri Jan 22 22:35:20 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E28A71065692 for ; Fri, 22 Jan 2010 22:35:19 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.ORG [206.117.18.8]) by mx1.freebsd.org (Postfix) with ESMTP id BA3F08FC16 for ; Fri, 22 Jan 2010 22:35:19 +0000 (UTC) Received: from [10.0.1.4] (pool-71-109-144-133.lsanca.dsl-w.verizon.net [71.109.144.133]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id o0MMZIpJ049658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Jan 2010 14:35:19 -0800 (PST) (envelope-from bc979@lafn.org) References: <4B594FC0.3010200@el.net> <4B5973AD.8070603@locolomo.org> <772FAD6A-C534-4217-9AA7-274561879E86@lafn.org> <4B59887E.30301@locolomo.org> In-Reply-To: <4B59887E.30301@locolomo.org> Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: Doug Hardie Date: Fri, 22 Jan 2010 14:35:17 -0800 To: Erik Norgaard X-Mailer: Apple Mail (2.1077) X-Virus-Scanned: clamav-milter 0.95.3 at zoom.lafn.org X-Virus-Status: Clean Cc: freebsd-questions - Subject: Re: pf rules X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2010 22:35:20 -0000 On 22 January 2010, at 03:14, Erik Norgaard wrote: > Doug Hardie wrote: >> On 22 January 2010, at 01:45, Erik Norgaard wrote: >>> To debug pf rules: >>>=20 >>> - 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 >>>=20 >>> then come back and ask for help. >> Where do you find the rule information in the pflog output from = tcpdump? =20 >=20 > a snip: >=20 > 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] >=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: >=20 > pass in quick on vr1 inet proto udp from 172.16.0.0/23 to = port =3D secret_service keep state >=20 > ofcourse, that rule didn't block. But two lines down I found: >=20 > block return in log quick on vr1 inet from 172.16.0.0/23 to >=20 > This makes sence, so why the offset 2? The first line of the output = from pfctl -sr is >=20 > scrub all fragment reassemble >=20 > that shouldn't count as a rule. And then, if pflog starts counting = with 0 while vi counts from 1 that explains it. >=20 > Yet another reason to check the rules as parsed using pfctl -sr. >=20 > 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. >=20 > My rules are grouped together like this: >=20 > # default policy > block all >=20 > block in log > pass in quick some packets keep state > block in log quick >=20 > block out log > pass out quick some packets keep state > block out log quick >=20 > # Default policy catch all should never apply > block log all >=20 > 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. >=20 > 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. >=20 > Once the ruleset is debugged and working you can remove the log = statements. Thanks. That is really helpful. The key is that the rule information = is in the link layer. I never guessed that. Now I see it just fine. = This approach sure beats monitoring the statistics and the input and = trying to correlate them. That was the approach I was using.