CODEWITHSUNDEEP
linuxtcp
M. Buil
M. Buil

Reputation: 569

Can TCP RST packet reduce the connection timeout?

As a way to learn how raw sockets work, I programmed a dummy firewall which drops the packets based on the TCP destination port. It is working but the problem is that the client retries for quite some time until the time out is finally reached.

I was wondering if perhaps the client retries for so long because it does not receive any answer. In that case, would it help if the firewall replies with a TCP RST to the TCP SYNC messages from the client? If not, is there any way to force the client to stop retrying (not reducing the timeout time in the Linux but more, getting a specific answer to its packets which will make the client stop)?

Upvotes: 1

Views: 2050

Answers (2)

user207421
user207421

Reputation: 310860

Your firewall is behaving correctly. It is a cardinal principle of information scurity not to disclose any information to the attacker. Sending an RST would disclose that the host exists.

There were firewalls that did that 15-20 years ago but there were frowned on. Nowadays they behave like yours: they just drop the packet and do nothing in reply.

It is normal for the client to retry a few times before giving up if there is no response, but contrary to what you have been told in comments, a client will give up immediately with 'connection refused' if it receives an RST. It only retries if there is no response at all.

Upvotes: 1

Joel Cunningham
Joel Cunningham

Reputation: 671

You can think of your firewall as the same case as if the port were closed on the host OS. What would the host OS's TCP/IP stack do?

RFC 793 (original TCP RFC) has the following to say about this case:

If the connection does not exist (CLOSED) then a reset is sent in response to any incoming segment except another reset. In particular, SYNs addressed to a non-existent connection are rejected by this means.

You should read the TCP RFCs and make sure your TCP RST packet conforms to the requirements for this case. A malformed RST will be ignored by the client.

RFC 1122 also indicates that ICMP Destination Unreachable containing codes 2-4 should cause an abort in the connection. It's important to note the codes because 0, 1, and 5 are listed as a MUST NOT for aborting the connection

Destination Unreachable -- codes 2-4

These are hard error conditions, so TCP SHOULD abort the connection.

Upvotes: 2

Related Questions