On Wed, 15 Aug 2018 08:05:13 -0700 "Doug Smythies" <dsmythies@xxxxxxxxx> wrote: > I do not have a file "/proc/net/nf_conntrack". If you are referring to examining > the conntrack table without using the conntrack tool, I used to love the old way > of using "/proc/net/ip_conntrack", but that disappeared about 3 years ago. I meant the exact file I listed, not "ip_conntrack". The "nf_conntrack" one is there for me in 4.14.62 (check your kernel config options?). But that's irrelevant for this discussion as using the tool should work too and will probably just return the same entries as in the file. > > And here's why it still works for me. In my case the rules are just: > > > > -A INPUT -m state --state INVALID -j DROP > > -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT > > -A INPUT -p tcp -m set --match-set myipv4 src -m tcp --dport 22 -j ACCEPT > > > > (the ipset part should be irrelevant) > > > > I accept everything to port 22, without involving -m conntrack. Personally I > > prefer the firewall to be as stateless as possible (and switched to fully > > stateless on several machines, at least on the IPv6 side). > > I thought "-m state" (which is what I always used until now) was just an > alias for "-m conntrack". Regardless, "-m state" doesn't work for me now > (iptables version 1.6.1-2ubuntu2). The difference is not "-m state" vs "-m conntrack" (and yes I heard they share the same implementation under the hood), but accepting all traffic on port 22, vs having a strict state filter as you have. In your case the "life" of your SSH connection lingers on there being an entry for it in the conntrack state table. As soon as "something happens" to that entry, there are no grounds anymore on which the firewall will pass on traffic for your established connection. And now with that kernel change it seems that something indeed "happens" to it on firewall resets. On the other hand as I have a plain "-A INPUT -p tcp --dport 22 -j ACCEPT", established connections don't depend on the conntrack table at all. So I was curious if you have a specific reason for locking it down that strictly, that I'm missing (and endangering my systems :). -- With respect, Roman
