From owner-freebsd-pf@FreeBSD.ORG Tue Jul 29 12:53:53 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 424031065677 for ; Tue, 29 Jul 2008 12:53:53 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from delusion.skoberne.net (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) by mx1.freebsd.org (Postfix) with ESMTP id EB6BE8FC0A for ; Tue, 29 Jul 2008 12:53:52 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (localhost [127.0.0.1]) by delusion.skoberne.net (Postfix) with ESMTP id 0F7E0B81A; Tue, 29 Jul 2008 14:53:51 +0200 (CEST) Received: from delusion.skoberne.net ([127.0.0.1]) by localhost (delusion.skoberne.net [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 91176-02; Tue, 29 Jul 2008 14:53:48 +0200 (CEST) Received: from [192.168.0.7] (pisarna.iskreni.net [213.143.68.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejkopejko@skoberne.net) by delusion.skoberne.net (Postfix) with ESMTP id 9860DB818; Tue, 29 Jul 2008 14:53:48 +0200 (CEST) Message-ID: <488F12DB.8090908@skoberne.net> Date: Tue, 29 Jul 2008 14:53:47 +0200 From: =?ISO-8859-2?Q?Nejc_=A9koberne?= User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Peter Wullinger References: <488EE046.4010602@skoberne.net> <488EE858.9010708@googlemail.com> In-Reply-To: <488EE858.9010708@googlemail.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Cc: freebsd-pf@freebsd.org Subject: Re: pf randomly blocks specific packets? 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: Tue, 29 Jul 2008 12:53:53 -0000 Hello, > Note: You can remove "keep state". This is implicit for newer version of > pf. > Note: These keep state, see above. You might want to add "no state" here, > to decrease state table usage. But if it is "no state" it means it eats more CPU? Or not? > From the frequency of the logs, it looks like that there is heavy load > on the server > (or a high connection latency). If so, this may be a problem of state > table exhaustion > or timeouts. pf may drop a "dangling, almost finished" connection before > the final "FIN" > packet arrives and thus create such log entries as the final packet gets > blocked, when the > corresponding state table entry is not present any more. Actually the server was just deployed and there shouldn't be much traffic going through. I checked with pfctl: State Table Total Rate current entries 79 searches 9652489 16.2/s inserts 486382 0.8/s removals 486303 0.8/s These seem pretty low, huh? > To eliminate this possibility, you should monitor the size of your state > table and possible increase the limits, if so. > Or insert some "no state" statements into your ruleset. So, what would be the next idea to try? For now I did "set skip on $int_Jails" and it seems to help. Thanks, Nejc