From owner-freebsd-net@freebsd.org Fri Jan 20 21:17:22 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 D8DD9CBA0E3 for ; Fri, 20 Jan 2017 21:17:22 +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 A24D21D79; Fri, 20 Jan 2017 21:17:22 +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 CEC4E35939; Fri, 20 Jan 2017 22:17:20 +0100 (CET) From: "Kristof Provost" To: "Ermal =?utf-8?q?Lu=C3=A7i?=" Cc: "Bakul Shah" , "FreeBSD Net" , "Alan Somers" Subject: Re: pf & NAT issue Date: Fri, 20 Jan 2017 22:17:20 +0100 Message-ID: In-Reply-To: References: <20170120083555.ACCF9124AEA4@mail.bitblocks.com> <7C29D00C-94C0-4550-B1B2-CE307482B544@FreeBSD.org> <20170120203106.CD2C8124AEA4@mail.bitblocks.com> <20170120205933.8948A124AEA3@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: Fri, 20 Jan 2017 21:17:22 -0000 On 20 Jan 2017, at 22:12, Ermal Luçi wrote: > Most probably your timeouts are aggressive on states garbage > collection. > Give a look to those state limit teardown it might improve things. > Less than 30 seconds seems extremely quick to time out. I also wouldn’t expect pf to set up NAT state in the middle of a TCP connection. It’s certainly worth a try to play with the timeouts though. It might be interesting to see what they’re set to right now. `pfctl -s all` should show them. Regards, Kristof