From owner-freebsd-pf@freebsd.org Wed Nov 25 10:52:22 2015 Return-Path: Delivered-To: freebsd-pf@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 2F81DA36C2B for ; Wed, 25 Nov 2015 10:52:22 +0000 (UTC) (envelope-from kp@vega.codepro.be) 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 ED5261B92 for ; Wed, 25 Nov 2015 10:52:21 +0000 (UTC) (envelope-from kp@vega.codepro.be) Received: from vega.codepro.be (unknown [172.16.1.3]) by venus.codepro.be (Postfix) with ESMTP id 6A596D7E9; Wed, 25 Nov 2015 11:52:18 +0100 (CET) Received: by vega.codepro.be (Postfix, from userid 1001) id 64D421AA45; Wed, 25 Nov 2015 11:52:18 +0100 (CET) Date: Wed, 25 Nov 2015 11:52:18 +0100 From: Kristof Provost To: J David Cc: freebsd-pf@freebsd.org Subject: Re: PF synproxy state =?utf-8?Q?doesn?= =?utf-8?B?4oCZdA==?= negotiate TCP options in 10.2 Message-ID: <20151125105218.GA2469@vega.codepro.be> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Checked-By-NSA: Probably User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 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: Wed, 25 Nov 2015 10:52:22 -0000 On 2015-11-25 05:36:07 (-0500), J David wrote: > It appears that “synproxy state” rules cause TCPs connection to be > negotiated without any options except MSS. > ... > Is this behavior intentional? If so, perhaps it should be mentioned > on the man page? If not, should we open a bug report on this? > It's 'intentional' in the sense that it's simply not implemented in pf. In the synproxy case pf generates the TCP packet from scratch. All that's implemented there is the MSS option. I suspect nothing more is implemented because of the complexity. Using synproxy means there's no communication with the 'real' server until the connection is (from the outside perspective) established, so pf can't really know what values to negotiate. You're right that it'd be good to document this in the man page though. Regards, Kristof