From owner-freebsd-net@freebsd.org Sat Jan 21 19:26:59 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F099CBB598 for ; Sat, 21 Jan 2017 19:26:59 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [IPv6:2a01:4f8:162:1127::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.codepro.be", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 078BBB0B; Sat, 21 Jan 2017 19:26:59 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from [10.0.2.164] (ptr-8ripyyfi1726l7ds8ua.18120a2.ip6.access.telenet.be [IPv6:2a02:1811:2419:4e02:4883:fabf:4b8b:94c2]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 6C0C435876; Sat, 21 Jan 2017 20:26:56 +0100 (CET) From: "Kristof Provost" To: "Bakul Shah" Cc: "Ermal =?utf-8?q?Lu=C3=A7i?=" , "FreeBSD Net" , "Alan Somers" Subject: Re: pf & NAT issue Date: Sat, 21 Jan 2017 20:26:55 +0100 Message-ID: <8C57C982-11BB-4BB4-97B7-4A5396336DB9@FreeBSD.org> In-Reply-To: <20170121042118.722C6124AEA4@mail.bitblocks.com> References: <20170120083555.ACCF9124AEA4@mail.bitblocks.com> <7C29D00C-94C0-4550-B1B2-CE307482B544@FreeBSD.org> <20170120203106.CD2C8124AEA4@mail.bitblocks.com> <20170120205933.8948A124AEA3@mail.bitblocks.com> <20170120211734.488D8124AEA5@mail.bitblocks.com> <20170121042118.722C6124AEA4@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6072) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 19:26:59 -0000 On 21 Jan 2017, at 5:21, Bakul Shah wrote: > I finally had some time to look at the sources & noticed > /sys/netpfil/pf/pf.c:pf_purge_thread now runs 10 times a > second instead of once a second, which gave me the idea of > increasing "interval" timeout by a factor of 10 and this seems > to have mostly fixed the problem. But I don't know where the > actual problem is. The logic is too complicated to understand > in a few minutes so I didn't try to find the root cause at the > moment. [But I don't understand why pf times out normal > connections. Long lasting idle connections are perfectly fine. Have you tried increasing the state limit? This sounds like your states are being cleaned up, which might happen because you’re running close to the limit. > And fragment GC should not be coupled with connection state > expiry] > I think that’s simply because they both need a timeout and it’s more efficient to handle both at the same time than to set two timers. Regards, Kristof