you still missed: succesful -> successful
On Wed, May 13, 2020 at 2:17 AM Jan Engelhardt <jeng...@inai.de> wrote: > > Signed-off-by: Jan Engelhardt <jeng...@inai.de> > --- > > Spello fix near "indiscriminately". > > 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..7387436c 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 indiscriminately 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..618a766c 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 indiscriminately 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 > Maciej Żenczykowski, Kernel Networking Developer @ Google
