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! _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[email protected]"
