Does TCP keepalive refresh the timeout on a NAT?

Question

I've read that NAT routers "assume a connection has been terminated if no data has been sent for a certain time period."

I've also read that TCP keepalive packets usually shouldn't contain any data.

So my questions are:

1. Are the above statements true?
2. Do NAT routers consider empty TCP keepalive packets when reordering/cleaning their tables?

I'm asking this because I need a reliable connection between two endpoints where both of them have to be able to detect and react to connection problems. I know that I might just implement a keepalive mechanism myself but I want to know whether the TCP implementation could be used for that.

Answer 1

I do believe the second statement refers to payload (The shortest possible TCP/IP packet is 40 bytes long - 20 bytes for TCP header + 20 bytes for IPv4 header).

Regarding the first, here's a quote from RFC 2663:

End of session for TCP, UDP and others

The end of a TCP session is detected when FIN is acknowledged by both halves of the session or when either half receives a segment with the RST bit in TCP flags field. However, because it is impossible for a NAT device to know whether the packets it sees will actually be delivered to the destination [...] the NAT device cannot safely assume that the segments containing FINs or SYNs will be the last packets of the session [...] Consequently, a session can be assumed to have been terminated only after a period of 4 minutes subsequent to this detection. The need for this extended wait period is described in RFC 793 [Ref 7], which suggests a TIME-WAIT duration of 2 * MSL (Maximum Segment Lifetime) or 4 minutes.

Reference: https://www.rfc-editor.org/rfc/rfc2663

To my understanding, any packets that identifies a session would reset the TTL counter - but that depends heavily on implementation, since 'data' can be understood as 'packet' (minimum 40 bytes) or 'packet payload'. Nonetheless, @CodeCaster is spot-on; never assume that a connection is alive, make sure it is before sending (and, if possible and depending on criticality, acknowledge receipt.)