From owner-freebsd-pf@FreeBSD.ORG Fri Mar 31 15:21:40 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 363D216A420 for ; Fri, 31 Mar 2006 15:21:40 +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 642B843D45 for ; Fri, 31 Mar 2006 15:21:37 +0000 (GMT) (envelope-from chris@xecu.net) Received: (qmail 26512 invoked from network); 31 Mar 2006 15:21:36 -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 15:21:36 -0000 Message-ID: <442D48F3.2020307@xecu.net> Date: Fri, 31 Mar 2006 10:21:23 -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: <000001c654d1$06bc4e60$0a00a8c0@thebeast> In-Reply-To: <000001c654d1$06bc4e60$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 15:21:40 -0000 Greg Hennessy wrote: >>I thought the most current recommendations were not to use >>polling? I thought this was something handled by most new hardware? >> >> > >I would use polling in any situation with the likelyhood of a high packet >rate, its integrated directly in the em NIC drivers as of 6.x and works a >treat through ifconfig. > > > I will implement polling and see if it helps. >>Altq is compiled in on this machine also, however, when not >>being used, I see the same result. I've seen many stories of >>600Meg/sec+, however, up until now, I have not been able to >>accomplish it. >> >> > >Hmmm, that sounds like a policy issue, 5.4 and em's iperf at > 900 meg/sec. > >What speed processor is driving this ? I assume you're using PCI-X >everywhere. > > > 2 of the nics are onboard, however the quad-port intel card is PCI-X. This is a 3.0Ghz pentium 4. >>I have switched this back he default. I get the same >>result. If I move the rule even 1 or 2 down in the list, >>traffic starts dropping on the http connections. I will >>leave it this way though. >> >> > >Hmmm, that sounds more and more like a state mismatch issue. > >What is your default block rule catching ? It should give you an idea pretty >quick regarding state mismatches due to overlapping rules. > >I assume your 1st rule is > >block log all > >If not, it should be. > > > The first rule is block log all. I put the http rules right after that rule, or I lose connections. The packets are not being logged as blocked. The just never show up on the internal nic. I can make this a bi-direction rule instead of keep state 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. >>>Are all your stateful tcp rules using flags S/SA to establish state ? >>> >>> >>> >>> >>> >>Not all of the rules are stateful, but the ones that are just >>use the "keep state" directive, they are not using S/SA. Is >>this the recommended method? >> >> > >Definitely, Daniel H has recently described the reasons why creating tcp >state on anything other than S/SA is a bad idea, especially with TCP window >scaling. > > > Is there a link to this information, or has it recently been added to the documentation? I would like to read the reasoning behind this. >>I have read many of the >>examples and docs, and it appears this is done both ways >>depending on where you read it. >> >> > >Personally I would use flags S/SA for all stateful tcp rules. > > > >>We have a lot of smtp traffic sometimes, so for those times, >>we have bumped up the state limit, however, at times like my >>testing last night, there were between 4000 and 5000 states, >>a few hundred at a time would be my testing. >> >> > >It may be worth using something like cricket to track the amount of state >table entries. > > > At peak times, the state table grows as large as 17000 states or so. At slow times, the table is in the 3000 - 5000 range. While testing last night, it was at the lower range. The state table size doesn't seem to affect the http connection drops. >>>With nearly 400 firewall rules, I would suggest that there's >>> >>> >>scope for >> >> >>>reviewing order and the judicious use of quick to trim the >>> >>> >>policy into >> >> >>>something more manageable. >>> >>> >>> >>> >>Well, this is something that was inherited, and therefore is >>taking much time to fix, however, the rules will be trimmed. >>I've already made extensive use of tables, and >>re-ordered/trimmed certain unnecessary things. >> >> > >If you havent done so already, start using tags in conjunction with generic >egress rules on each interface. This will reduce the rulebase in size a lot. > > Generic egress rules are a little difficult because I'm trying to do traffic shaping of certain traffic. 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. I'm no developer, so I don't know the code involved, so I could definitely be wrong about this. Since more manageable rulesets were brought up, does the optimizer really do anything, or is that just asking for trouble? Chris