From owner-freebsd-net@FreeBSD.ORG Sun Apr 6 11:02:50 2014 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D9880ED1 for ; Sun, 6 Apr 2014 11:02:50 +0000 (UTC) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4988D1DB for ; Sun, 6 Apr 2014 11:02:49 +0000 (UTC) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221]) by hz.grosbein.net (8.14.7/8.14.7) with ESMTP id s36B2ja9082297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Apr 2014 13:02:46 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: net@freebsd.org Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.7/8.14.7) with ESMTP id s36B2f8t064764; Sun, 6 Apr 2014 18:02:41 +0700 (NOVT) (envelope-from eugen@grosbein.net) Message-ID: <53413451.4080400@grosbein.net> Date: Sun, 06 Apr 2014 18:02:41 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130415 Thunderbird/17.0.5 MIME-Version: 1.0 To: Brett Glass Subject: Re: More on odd IPFW behavior References: <201404060427.WAA11607@mail.lariat.net> In-Reply-To: <201404060427.WAA11607@mail.lariat.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=3.2 required=5.0 tests=BAYES_00, DATE_IN_FUTURE_96_Q, LOCAL_FROM autolearn=no version=3.3.2 X-Spam-Report: * 2.9 DATE_IN_FUTURE_96_Q Date: is 4 days to 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on hz.grosbein.net X-Spam-Level: *** Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 11:02:50 -0000 On 06.04.2014 11:27, Brett Glass wrote: > A bit more investigation of IPFW's behavior on VLAN interfaces has > revealed some even stranger stuff. Consider the tallies on the > following firewall rules: > > # ipfw show | head > 00001 65071 36685513 count ip from any to any layer2 via re0 > 00002 65303 36856334 count ip from any to any layer2 via re0_1 > 00003 6 3381 count ip from any to any layer2 via re0_2 > 00004 49338 35208527 count ip from any to any layer2 via re0_3 > 00005 0 0 count ip from any to any layer2 in recv re0 > 00006 65071 36685513 count ip from any to any layer2 out xmit re0 > 00007 0 0 count ip from any to any layer2 in recv re0_1 > 00008 65303 36856334 count ip from any to any layer2 out xmit re0_1 > > It looks as if, when one adds "in" and "out" to the rules, one > never sees any Layer 2 packets coming "in" on either a vlan(4) > interface or its parent. There might be a problem with general > brokenness in IPFW's "in" and "out" qualifiers when dealing with > Layer 2 packets, or something else might be wrong.... Not sure, but > this behavior is definitely weird. And note that, again, re0_1 (a > child interface) shows more packets than re0 (the parent). Weird. > Do not have experience with pf, so do not know if it would do > better, but IPFW certainly has something broken. Help in figuring > out what to propose as a patch would be MUCH appreciated. Try to replace "count" with "allow" in the rule 6 and "count" with "count log" in the rule 8 and look at /var/log/security to find out "extra" packets that hit rule 8.