Doug Smythies <dsmyth...@telus.net> wrote: > 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.
> > 4d3a57f23dec59f0a2362e63540b2d01b37afe0a is the first bad commit > commit 4d3a57f23dec59f0a2362e63540b2d01b37afe0a > Author: Florian Westphal <f...@strlen.de> > Date: Fri Jul 28 11:22:04 2017 +0200 > > netfilter: conntrack: do not enable connection tracking unless needed [..] > 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. Its because lazy pickup turns off window validation. net.netfilter.nf_conntrack_tcp_be_liberal=1 will also make it "work" for all other connections. I can think of 3 ways to fix it. 1. make nf_ct_netns_do_put defer unreg to a work queue and wait for a few seconds. This would allow a removal of all rules + immediate re-add keep conntrack hooks in place. 2. remove nf_ct_netns_put. conntrack can't be disabled anymore without rmmod after this. 3. make nf_ct_nets_put clear the conntrack table and rely on loose=1 mode Seems option 1) would be the best solution. BTW, there should be no breakage when ipables rules are simply re-loaded via iptables-restore from "known good" copy. This only occurs when all rules are removed, then re-added. > 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. Conntrack did not see some packets so once it sees them again all sequence numbers are invalid.
