Signed-off-by: Jan Engelhardt <jengelh@xxxxxxx> --- Simplify the trigger case by dropping mentions of P_3. New -A commands as proposed. extensions/libip6t_REJECT.man | 20 ++++++++++++++++++++ extensions/libipt_REJECT.man | 20 ++++++++++++++++++++ 2 files changed, 40 insertions(+) diff --git a/extensions/libip6t_REJECT.man b/extensions/libip6t_REJECT.man index 0030a51f..cc845e6f 100644 --- a/extensions/libip6t_REJECT.man +++ b/extensions/libip6t_REJECT.man @@ -30,3 +30,23 @@ 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 transmitting a packet P, with P experiencing so much +delay along its path that the source host issues a retransmission, P_2, with +P_2 being succesful in reaching its destination and advancing the connection +state normally. It is conceivable that the late-arriving P may be considered to +be not associated with any connection tracking entry. Generating a reject +packet for this packet would then terminate the healthy connection. +.PP +So, instead of: +.PP +-A INPUT ... -j REJECT +.PP +do consider using: +.PP +-A INPUT ... -m conntrack --ctstate INVALID -j DROP +-A INPUT ... -j REJECT diff --git a/extensions/libipt_REJECT.man b/extensions/libipt_REJECT.man index 8a360ce7..08a1955c 100644 --- a/extensions/libipt_REJECT.man +++ b/extensions/libipt_REJECT.man @@ -30,3 +30,23 @@ 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 transmitting a packet P, with P experiencing so much +delay along its path that the source host issues a retransmission, P_2, with +P_2 being succesful in reaching its destination and advancing the connection +state normally. It is conceivable that the late-arriving P may be considered to +be not associated with any connection tracking entry. Generating a reject +packet for this packet would then terminate the healthy connection. +.PP +So, instead of: +.PP +-A INPUT ... -j REJECT +.PP +do consider using: +.PP +-A INPUT ... -m conntrack --ctstate INVALID -j DROP +-A INPUT ... -j REJECT -- 2.26.2
