Why are some tcp packets with the RST flag classified as new incoming connection?

Question

While looking through my iptables log, I keep observing periodically incoming connections with the RESET flag being set from a few ip addresses within my ISP's network. This is a sample tcpdump on one of those connections:

22:18:13.026881 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [S]  seq 3805987202     win 29200  options [mss 1460 sackOK TS val 3031189 ecr 0 nop wscale 7]  length 0  
22:18:13.032076 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [S.]  seq 738249760  ack 3805987203  win 29200  options [mss 1460 nop nop sackOK nop wscale 6]  length 0     
22:18:13.032151 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738249761  ack 1  win 229  length 0 
22:18:13.032415 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [P.]  seq 3805987203:3805987396  ack 1  win 229  length 193 
22:18:13.036553 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [.]   3805987396  ack 194  win 473  length 0 
22:18:13.042920 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [.]  seq 738249761:738251221  ack 194  win 473  length 1460 
22:18:13.042979 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738251221  ack 1461  win 251  length 0 
22:18:13.043133 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [P.]  seq 738251221:738251809  ack 194  win 473  length 588 
....
22:20:10.652745 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738254876  ack 5116  win 365  length 0 
22:21:09.649107 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [P.]  seq 3805988348:3805988389  ack 5116  win 365  length 41 
22:21:09.657454 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [P.]  seq 738254876:738254921  ack 1187  win 509  length 45 
22:21:09.657498 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738254921  ack 5161  win 365  length 0 
22:21:09.657612 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [P.]  seq 3805988389:3805988434  ack 5161  win 365  length 45 
22:21:09.657748 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [FP.]  seq 3805988434:3805988465  ack 5161  win 365  length 31 
22:21:09.660431 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [F.]  seq 738254921  ack 1187  win 509  length 0 
22:21:09.660467 IP 192.168.1.2.43948 > XX.XX.X.103.443: Flags [.]   738254922  ack 5162  win 365  length 0 
22:21:09.667156 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [R]  seq 738254921     win 0  length 0 
22:21:09.667923 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [R]  seq 738254921     win 0  length 0 
22:21:09.667971 IP XX.XX.X.103.443 > 192.168.1.2.43948: Flags [R]  seq 738254922     win 0  length 0 

The tcp sequence number is continuous. Shouldn't it be considered as part of an established connection using the rule in iptables below:

-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

Solution 1

A TCP Reset is an un-acknowledged method of terminating a TCP connection. Typically reserved for the case that something went wrong, and needing a quick way to start over (after the RST).

If in the midst of your TCP connection, if you receive a RST from the same Protocol, Source IP, Source Port, Destination IP, Destination Port (known also as a Five-Tuple), you would classify that packet as being received "within" the established connection.

If, however, you are the entity sending the RST, you would instantly purge your connection information after sending the RST. If, at that point, the other end decided to send a TCP RST, upon receiving it you would have no knowledge of that particular "Five-Tuple" (since you just purged that knowledge), so you would consider the packet you just received a "New" connection -- which would than instantly be purged from your connection table again, since that is what should be done in response to a RST packet.

So in short, to answer your question. Your machine would mark a RST packet as a new connection if it had no prior knowledge of the connection (aka, the five-tuple) within which the RST was sent.

Solution 2

Looks like the server is hard closing the connection.

Here's some info on TCP RST: TCP uses the RST (Reset) bit in the TCP header to reset a TCP connection. Resets are appropriately sent in response to a connection request to a nonexistent connection, for example. The TCP receiver of the reset aborts the TCP connection, and notifies the application [RFC793, RFC1122, Ste94].

Also this thread seems related and pertinent: What is the reason and how to avoid the [FIN, ACK] , [RST] and [RST, ACK]

Comments

[LawrenceC]

Comcast in the mid 200x's was doing this for connections it suspected were P2P. Not sure if that is still the case - intermediate network devices or security software might do this. An iptables workaround for Linux systems was possible by ignoring incoming RST's that were also new.

[Question Overflow]

Thanks for clarifying the part on RST. As you can see from the above, my machine did not send any RST packet. This is done by the other party thrice. The first two are being recorded as NEW incoming. The last one seems to fall under established as it is not logged by iptables. Shouldn't the connection be purged immediately after both parties send FIN?