Bdtyktl

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

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.

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]

I've observed this behaviour with some clients on my network when I had for one segment MTU mismatch -- normal MTU is 1500, but the segment's routers had 1300 eventually timing out client's packets and PUSH'es not reaching their destination and the other side started to RST. Fixing the MTU for the segment let the problem go away.