On Thu, Aug 23, 2018 at 02:28:24PM -0700, Doug Smythies wrote:
> On 2018.08.23 11:16 Pablo Neira Ayuso wrote:
> > On Wed, Aug 22, 2018 at 05:05:14PM -0700, Doug Smythies wrote:
> >> On 2018.08.22 11:26 Doug Smythies wrote:
> >>> On 2018.08.21 02:26 Florian Westphal wrote:
> >>>
> >>> ... [snip] ...
> >>>
> >>>> Fix this by clearing maxwin of existing tcp connections on register.
> >>>> While at it, lower timeout of existing entries when disabling to allow
> >>>> gc to reap entries more quickly.
> >>>>
> >>>> Reported-by: Doug Smythies <dsmythies@xxxxxxxxx>
> >>>> Fixes: 4d3a57f23dec59 ("netfilter: conntrack: do not enable connection tracking unless needed")
> >>>> Signed-off-by: Florian Westphal <fw@xxxxxxxxx>
> >>>> ---
> >>>> net/netfilter/nf_conntrack_proto.c | 61 ++++++++++++++++++++++++++++++++++++--
> >>>> 1 file changed, 59 insertions(+), 2 deletions(-)
> >>>
> >>> ... [snip] ...
> >>>
> >>> I was not able to apply this patch on top of kernel 4.18, as it
> >>> seems to be on top of other patches since then.
> >>>
> >>> I was able to apply it on top of the mainline kernel as of sometime
> >>> yesterday (head was at ad1d697)(somewhere between 4.18 and 4.19-rc1).
> >>>
> >>> I verified that as of ad1d697 the issue was still present and then
> >>> tested ad1d697 + this patch and the issue is fixed.
> >>>
> >>
> >> I spoke too soon. Now I have issues with any other SSH sessions
> >> dropping out if I don't use them within one minute of an iptables rule
> >> set flush and re-load.
> >>
> >> The previous suggested change:
> >>
> >> echo 1 | sudo tee /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal
> >>
> >> does not fix it.
> >
> > Could you try conntrack -F after removing your ruleset?
>
> ad1d697 + this patch:
>
> O.K. that eliminates the 1 minute wait, and the other ssh connections
> drop right away when I try to use them, after ruleset is loaded again.
> The ssh session I ran the commands from is fine, usually.
> I've tried it multiple ways and with / without nf_conntrack_tcp_be_liberal
>
> ad1d697 reference kernel:
>
> The other ssh sessions drop out, but the one the commands were run from
> does not, basically the opposite of what used to occur.
For the sake of clarity, did you try with `conntrack -F'?
I suspect the issue is the following: After ruleset goes away,
conntrack hooks are unregistered as this patch describes but entries
are still left in the table. Follow up packets don't hit conntrack
since hooks are unregistered, but once conntrack gets registered
again, the packets hit the stale entries.
That's why I'm asking you to give a try to `conntrack -F', because we
may need a conntrack table flush once all entries are gone.
