From owner-freebsd-pf@freebsd.org Wed Nov 25 10:36:08 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 3EDA4A36846 for ; Wed, 25 Nov 2015 10:36:08 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D7AB146B for ; Wed, 25 Nov 2015 10:36:08 +0000 (UTC) (envelope-from jdavidlists@gmail.com) Received: by igbxm8 with SMTP id xm8so34932827igb.1 for ; Wed, 25 Nov 2015 02:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3kUgtPTIZHiuoqgB5CiONhX+6jx5GlW1dvZ3r8fEG88=; b=kLooaE/oRO9W5TUg7b3y/soVFNManGawsZlU7w0XDxWtnBfIua8G2T5fhJmzpTLGu7 wwHY5oeI9zcIWPjwLFhLOALuLV+CDvmN1wnBfQkhB6Ag7vACcPVOVpM3NJqLtSQZO5uW /eGk2dsCl+QtPgev+QMPNPvEzMzKnwTN3dO1VJyKjCpiF3YHLSX2zL5BfYViVlh37R+z jU6HjENR4FwZ+ZljvXTGfQMmDFZIk716P05NVmDL1a/ZumQXlCRpQQ5k67AdErDTQavW kPHa0YVtdxW2eYw2tsn8uN/HySnKp//tcwLxLEYLVa/jPOrmpc/NrG+lUKT2NKNjTVmW nXdg== MIME-Version: 1.0 X-Received: by 10.50.57.44 with SMTP id f12mr3149586igq.29.1448447767146; Wed, 25 Nov 2015 02:36:07 -0800 (PST) Sender: jdavidlists@gmail.com Received: by 10.36.91.10 with HTTP; Wed, 25 Nov 2015 02:36:07 -0800 (PST) Date: Wed, 25 Nov 2015 05:36:07 -0500 X-Google-Sender-Auth: U0ACQgqzNyhgbw8GXyY99ZbTjKo Message-ID: Subject: =?UTF-8?Q?PF_synproxy_state_doesn=E2=80=99t_negotiate_TCP_options_in?= =?UTF-8?Q?_10=2E2?= From: J David To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:36:08 -0000 It appears that =E2=80=9Csynproxy state=E2=80=9D rules cause TCPs connectio= n to be negotiated without any options except MSS. Notably, it prevents the connection from using window scaling and selective-ACK, which can seriously limit throughput in many cases. Here=E2=80=99s a tcpdump of SYN and SYN ACK for a client and server with a synproxy state rule for HTTP on the server side: 10:15:04.038953 IP client.49266 > server.80: Flags [S], seq 2525361772, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS val 730329818 ecr 0], length 0 10:15:04.111492 IP server.80 > client.49266: Flags [S.], seq 67243122, ack 2525361773, win 0, options [mss 1460], length 0 Here is the same tcpdump with the =E2=80=9Csynproxy state=E2=80=9D rule cha= nged to =E2=80=9Ckeep state:=E2=80=9D 10:30:51.169885 IP client.38552 > server.80: Flags [S], seq 719298516, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS val 731276949 ecr 0], length 0 10:30:51.241967 IP server.80 > client.38552: Flags [S.], seq 3305307963, ack 719298517, win 65535, options [mss 1460,nop,wscale 9,sackOK,TS val 1216301733 ecr 731276949], length 0 In the test case these tcpdumps are taken from, the throughput difference between the two otherwise-identical rules is a factor of 10x. 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? Thanks!