Signed-off-by: Jan Engelhardt <jengelh@xxxxxxx> --- Maciej's explanation on how INVALID+REJECT can lead to problems looks convincing. I hereby present new manpage wording in the form of "if A, then B" to better build the argument of avoiding REJECT. So the issue is not caused by an _incoming_ TCP RST as the initial mail might have suggested, but by RST generated by REJECT (--reject-with tcp-reset). It is conceivable to me that a connection termination may occur with not only TCP+RST, but also with TCP+ICMP and UDP+ICMP, so I trimmed any protocol-specific wording too. Also trimmed is any mention of -j ACCEPT, because rule order is not the point of the argument. extensions/libip6t_REJECT.man | 21 +++++++++++++++++++++ extensions/libipt_REJECT.man | 21 +++++++++++++++++++++ 2 files changed, 42 insertions(+) diff --git a/extensions/libip6t_REJECT.man b/extensions/libip6t_REJECT.man index 0030a51f..38183dd7 100644 --- a/extensions/libip6t_REJECT.man +++ b/extensions/libip6t_REJECT.man @@ -30,3 +30,24 @@ TCP RST packet to be sent back. This is mainly useful for blocking hosts (which won't accept your mail otherwise). \fBtcp\-reset\fP can only be used with kernel versions 2.6.14 or later. +.PP +\fIWarning:\fP You should not indiscrimnately apply the REJECT target to +packets whose connection state is classified as INVALID; instead, you should +only DROP these: +.PP +Consider a source host retransmitting an original packet P as P_2 for any +reason, and P_2 getting routed via a different path (load balancing/policy +routing, or anything of the kind). Additionally, let P_2 experience so much +delay that the source host issues \fIanother\fP retransmission, P_3, with P_3 +being succesful in reaching its destination and advancing the connection state +normally. The delayed P_2, when it eventually is processed, may be considered +to be not associated with any connection tracking entry. Generating a reject +packet for such a belated packet would then terminate the healthy connection. +.PP +So, instead of: +.PP +-A INPUT -m conntrack --ctstate INVALID -j REJECT +.PP +do consider using: +.PP +-A INPUT -m conntrack --ctstate INVALID -j DROP diff --git a/extensions/libipt_REJECT.man b/extensions/libipt_REJECT.man index 8a360ce7..9e80d7ea 100644 --- a/extensions/libipt_REJECT.man +++ b/extensions/libipt_REJECT.man @@ -30,3 +30,24 @@ TCP RST packet to be sent back. This is mainly useful for blocking hosts (which won't accept your mail otherwise). .IP (*) Using icmp\-admin\-prohibited with kernels that do not support it will result in a plain DROP instead of REJECT +.PP +\fIWarning:\fP You should not indiscrimnately apply the REJECT target to +packets whose connection state is classified as INVALID; instead, you should +only DROP these: +.PP +Consider a source host retransmitting an original packet P as P_2 for any +reason, and P_2 getting routed via a different path (load balancing/policy +routing, or anything of the kind). Additionally, let P_2 experience so much +delay that the source host issues \fIanother\fP retransmission, P_3, with P_3 +being succesful in reaching its destination and advancing the connection state +normally. The delayed P_2, when it eventually is processed, may be considered +to be not associated with any connection tracking entry. Generating a reject +packet for such a belated packet would then terminate the healthy connection. +.PP +So, instead of: +.PP +-A INPUT -m conntrack --ctstate INVALID -j REJECT +.PP +do consider using: +.PP +-A INPUT -m conntrack --ctstate INVALID -j DROP -- 2.26.2
