Date: Wed, 25 Nov 2015 05:36:07 -0500 From: J David <j.david.lists@gmail.com> To: freebsd-pf@freebsd.org Subject: =?UTF-8?Q?PF_synproxy_state_doesn=E2=80=99t_negotiate_TCP_options_in?= =?UTF-8?Q?_10=2E2?= Message-ID: <CABXB=RRuzgKk44TGmtJ0Nfx21Z2Ef-bMEF4hpe1sH9%2BNLkf3Dw@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABXB=RRuzgKk44TGmtJ0Nfx21Z2Ef-bMEF4hpe1sH9%2BNLkf3Dw>