Hi Florian, Thanks for your quick reply, and the time you took to do it. On 2018.08.14 11:01 Florian Westphal wrote: > Doug Smythies <dsmythies@xxxxxxxxx> 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 <fw@xxxxxxxxx> >> 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. Yes, that seems to work, thanks. > 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. Except that often the workflow is: Removal of all rules; So some stuff; Then re apply the rules. My preference is option 2, however this is not my area of expertise, so I defer to the subject matter experts. > BTW, there should be no breakage when ipables rules are simply > re-loaded via iptables-restore from "known good" copy. I won't bore you with the reasons, but I no longer use iptables-restore (I used to). I use a script, so that some related, but not iptables rules, things can be done in the same script. > This only occurs when all rules are removed, then re-added. Agreed. >> 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. Oh, that now makes sense. Thanks for explaining. ... Doug Smythies
