The client 192.168.220.106:49194 is at fault. It establishes the connection, then tears it down with these packets:
> 10:17:14.444212 192.168.220.106.49194 > 192.168.221.20.993: FP > 2634574252:2634574289(37) ack 1101857573 win 65535 <nop,nop,timestamp > 1476581199 3164056005> (DF) (ttl 64, id 25617, len 89) > 10:17:14.444286 192.168.220.106.49194 > 192.168.221.20.993: R [tcp sum ok] > 2634574252:2634574252(0) win 0 (ttl 64, id 25618, len 40) After the (valid) FIN, the connection is half-closed. That is, the client told the server that it is finished sending data. The server is allowed to send further data (until it sends itself a FIN, fully closing the connection). But the client doesn't seem to want to read further data from the server, and sends a RST. But the sequence number (th_seq) used in the RST is not valid. It should be 2634574290 (past the last segment the client sent), not 2634574252 (past the second-to-last segment, not including the payload in the FIN+PSH). This looks like a bug in the client's TCP/IP stack, and how to fix it depends on the client's OS. IMO, the RST is invalid, and pf is right in blocking it. More details are found in RFC 793 (Transmission Control Protocol), especially Reset Processing In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. where "in the window" means A segment is judged to occupy a portion of valid receive sequence space if RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND where "RCV.NXT" means RCV.NXT = next sequence number expected on an incoming segments, and is the left or lower edge of the receive window The point is that the sender's FIN+PSH has advanced the receiver's RCV.NXT to 2634574290, and the sender should know that. Daniel