Hi Neal , Typically , not always , many IPTABLES FIREWALLS have very simple rules going OUT from "self" ignoring state leaving the host . ( If this is incorrect , I think is more of an long semantic discussion .) Either way , that would most likely be the reason you are experiencing this issue , >From a more practical standpoint , any and all firewalls cannot "detect" closed connection ... ... it can only compare sessions with the ones that are recorded in the connection table . As soon as any connection is deleted from connection table , it is no longer VALID/KNOWN from a technical standpoint . How your firewall handles these "packets" then is up to your rules , and if you allow them going out from one self via OUTPUT filter chain but block them going in another host via the INPUT filter chain you will experience some packets being blocked as INVALID only when going into the hosts . ( so yes you can change this behavior to also block "unknown" session going out , just make sure you allow "known" sessions first ) Best regards André Paulsberg-Csibi Senior Network Engineer Fault Handling IBM Services AS andre.paulsberg-csibi@xxxxxxxx M +47 9070 5988 -----Original Message----- From: netfilter-owner@xxxxxxxxxxxxxxx [mailto:netfilter-owner@xxxxxxxxxxxxxxx] On Behalf Of Neal P. Murphy Sent: 30. april 2016 01:51 To: netfilter@xxxxxxxxxxxxxxx Subject: bursts of INVALID packets Kernel: 3.4.112 Iptables: 1.4.21 System: Smoothwall Express 3.1 This isn't exactly a problem; it's more of an oddity that raises some questions. Take two linux systems. Using ssh (and a shell script), transfer /dev/zero from one to /dev/null on the other. With a decent system and 100Mb NICs, they should climb to about 97Mb/s in and out. Very nice. Now interrupt one with CTRL/C. All of a sudden, a burst of INVALID RST packets arrives at (at least) one side. The number of packets in the burst can be from few to many. I surmise that one side buffered a bunch of packets and continued to transmit them after the transfer was interrupted. The other side received these packets, noted the now-closed connection, and sent RST packets back. The one side, upon receiving the RST packets, marked them INVALID and logged them. All is working as expected. This leads to my questions. Can (or could, or should) netfilter detect that outgoing packets belong to closed conns and mark them INVALID? Should netfilter be able to detect and drop INVALID packets on output? Or, as an alternative, should netfilter be able to see that a conn is closed and mark outgoing packets INVALID so that rules can handle them? Is it worth the CPU cycles to do this? Dropping INVALID packets on input (mangle:PREROUTING) works marvelously. Of course, if the outgoing packets have already left netfilter and are queued for transmission, netfilter is out of the loop and cannot stop them. Aside, I've bumped SWE3.2 to iptables 1.6.0; but it'll be a long while before 3.2 is releasable. Thanks, Neal -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
