PF synproxy state doesn’t negotiate TCP options in 10.2

[J David]

It appears that “synproxy state” rules cause TCPs connection 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’s 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 “synproxy state” rule changed to “keep state:”

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!