iptables reject-with tcp-reset without ACK flag

Question

I created iptables rule:

iptables -I INPUT -p tcp --tcp-flags SYN,RST,ACK,FIN SYN --dport 10000 -j REJECT --reject-with tcp-reset

But actually, what this does is a rejecting all packets with RST and ACK flags.

It is possible to reject only with RST flag set?

I know that in a normal environment this does not give any sense, but I have a lab and I need to do exactly as described.

Answer 1

I'm in China, so before I do dig +tcp twiter.com @1.1.1.1, I need do these 2 lines:

sudo iptables -A INPUT -p tcp -s 1.1.1.1/32 --tcp-flags ALL RST,ACK -j DROP
sudo iptables -A INPUT -p tcp -s 1.1.1.1/32 --tcp-flags ALL RST -j DROP

Then I'll get the right answer:

;; ANSWER SECTION:
twitter.com.        204 IN  A   104.244.42.65

If I only do the 1st iptables command, my dig will fail:

";; communications error to 1.1.1.1#53: connection reset"

The Great Firewall of China is weird...

Answer 2

To drop inbound RST packets,

  iptables -I INPUT -p tcp --tcp-flags ALL RST,ACK  --dport 10000 -j DROP

To drop outboud RST Packets,

  iptables -I OUTPUT -p tcp --tcp-flags ALL RST,ACK --dport 10000 -j DROP

FYR:

URL : https://networkengineering.stackexchange.com/questions/2012/why-do-i-see-a-rst-ack-packet-instead-of-a-rst-packet

A RST/ACK is not an acknowledgement of a RST, same as a SYN/ACK is not exactly an acknowledgment of a SYN. TCP establishment actually is a four-way process: Initiating host sends a SYN to the receiving host, which sends an ACK for that SYN. Receiving host sends a SYN to the initiating host, which sends an ACK back. This establishes stateful communication.

SYN --> 
    <-- ACK
    <-- SYN
ACK -->

To make this more efficient, the receiving host can ACK the SYN, and send its own SYN in the same packet, creating the three-way process we are used to seeing.

SYN -->
    <-- SYN/ACK
ACK -->

In the case of a RST/ACK, The device is acknowledging whatever data was sent in the previous packet(s) in the sequence with an ACK and then notifying the sender that the connection has closed with the RST. The device is simply combining the two packets into one, just like a SYN/ACK. A RST/ACK is usually not a normal response in closing a TCP session, but it's not necessarily indicative of a problem either.