From owner-freebsd-pf@FreeBSD.ORG Fri Mar 31 23:38:21 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A21216A420 for ; Fri, 31 Mar 2006 23:38:21 +0000 (UTC) (envelope-from chris@xecu.net) Received: from mss2.myactv.net (mss2.myactv.net [24.89.0.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 8404D43D4C for ; Fri, 31 Mar 2006 23:38:20 +0000 (GMT) (envelope-from chris@xecu.net) Received: (qmail 8500 invoked from network); 31 Mar 2006 23:38:19 -0000 Received: from dyn-24-13.myactv.net (HELO ?192.168.1.86?) (24.89.24.13) by mss2.myactv.net with SMTP; 31 Mar 2006 23:38:19 -0000 Message-ID: <442DBD5E.3090905@xecu.net> Date: Fri, 31 Mar 2006 18:38:06 -0500 From: Christopher McGee User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Hennessy References: <000001c654db$a5203440$0a00a8c0@thebeast> In-Reply-To: <000001c654db$a5203440$0a00a8c0@thebeast> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: Traffic mysteriously dropping X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 23:38:21 -0000 Greg Hennessy wrote: >>The first rule is block log all. I put the http rules right >>after that rule, or I lose connections. >> >> > >I would suggest minimising the amount of non stateful rules in the policy. >They have a habit of biting one in the rear. > > > There are only 3 or 4 rules in the ruleset that are non-stateful. I can try to eliminate those also. >>The packets are not being logged as >>blocked. >> >> > >A block further down the policy without a 'log' may cause this. > >One of the joys of debugging a last match policy. > > > All rules that are block are also using log. A lot of the pass rules do not because it generates such enormous logs. I can try enable logging on every rule temporarily in order to troubleshoot this if necessary. >>The just never show up on the internal nic. >> >> > >I take it you've simultaneously tcpdumped both ingress and egress interfaces >to confirm this ? Packets disappearing during traversal implies a routing >issue. > > > Yes, if I tcpdump on em0, pflog0, and em1 simultaneously during a traffic test, the traffic hits em0, and never shows up as blocked in pflog0 and never shows up at all on em1. As I stated, it's only 1 out of a bunch of connections, so there is no rule blocking all the traffic. > > >>I can make this a bi-direction rule instead of keep state >> >> > >That's inefficient as each packet forces a rule base traversal. > >Try coding a tcp flow as > >pass log quick on em inet proto tcp from source to dest port something keep >state flags S/SA > > >I said 'em' above, not em[0-9]. > >Using interface groups without directionality, means that a single rule will >match the flow on both the ingress and egress interfaces. > >Combined with antispoof, it makes for simpler policy > > > I have coded the rule as explained above and even as the first rule after the default block rule, it still drops traffic. If I change it to non-stateful, it doesn't drop the connections. I can't seem to get away from the thought of a state mis-match, however, I don't know why it would consistently do it on these http connections. >>and it still drops traffic if I >>move it down in the list. If I leave it where it is, and >>make it a keep state rule, it drops the connections also. >> >> > >What other blocks are in the policy ? > > > I don't believe I'm doing any specifc blocks. Just the default block and then allow what we need after that. >>At peak times, the state table grows as large as 17000 states >>or so. >> >> > >If that's the case, the default table size is inadequate, I would set it to >at least 25000. > > > I bumped up the state limit a long time ago. I haven't run into issues with that. There is adequate room in the state table even during peak times. Unfortunately, it's dropping the traffic even during slow times. >>Generic egress rules are a little difficult because I'm trying to do >>traffic shaping of certain traffic. >> >> > >Get the policy working without drops 1st, then shape. > > > Agreed, altq has been disabled until I can get the traffic flowing smoothly. >>A side note, the machine is not doing any NAT. Tagging seems like it >> >> >would require more > > >>overhead than what the firewall is doing already. >> >> > >It doesn't. Tagging works per stateful flow, not per packet. Using tagging >will permit you to significantly reduce the size of the rulebase. > > > The ruleset will be getting a significant rewrite, however, time has not permitted it yet. Chris