Hi,
Sometimes it is desirable to temporarily disable, or clear,
the iptables rule set on a computer being controlled via a
secure shell session (SSH). While unwise on an internet facing
computer, I also do it often on non-internet accessible computers
while testing. Recently, this has become problematic, with the
SSH session being dropped upon re-load of the rule set.
The kernel was bisected and the issue isolated to:
4d3a57f23dec59f0a2362e63540b2d01b37afe0a is the first bad commit
commit 4d3a57f23dec59f0a2362e63540b2d01b37afe0a
Author: Florian Westphal <fw@xxxxxxxxx>
Date: Fri Jul 28 11:22:04 2017 +0200
netfilter: conntrack: do not enable connection tracking unless needed
Discussion during NFWS 2017 in Faro has shown that the current
conntrack behaviour is unreasonable.
Even if conntrack module is loaded on behalf of a single net namespace,
its turned on for all namespaces, which is expensive. Commit
481fa373476 ("netfilter: conntrack: add nf_conntrack_default_on sysctl")
attempted to provide an alternative to the 'default on' behaviour by
adding a sysctl to change it.
However, as Eric points out, the sysctl only becomes available
once the module is loaded, and then its too late.
So we either have to move the sysctl to the core, or, alternatively,
change conntrack to become active only once the rule set requires this.
This does the latter, conntrack is only enabled when a rule needs it.
Reported-by: Eric Dumazet <edumazet@xxxxxxxxxx>
Signed-off-by: Florian Westphal <fw@xxxxxxxxx>
Signed-off-by: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
Since I sometimes (O.K. often) mess up using git bisect, and end up at some
random result, the above was double checked and confirmed manually.
The issue has been confirmed on multiple computers and methods.
The issue has been verified to still exist with kernel 4.18.
There are potentially confusing scenarios, where it seems to work fine.
Any SSH session started with no iptables rule set will work fine,
it has to be a session that was started with the rule set in place.
Typically after boot, with an automatically loaded rule set.
It seems as though the resulting iptables rule set has forgotten
the association with that particular connection and therefore
classifies any incoming packets as invalid. Somehow the connection tracking
table has become confused and the packet is not even considered NEW, but with
incorrect flags, nor is it considered part of the existing connection.
Doug Smythies
