Please consider the following piece of our firewall script's output: ---- * Setting up connection tracking for already-active traffic iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT iptables -A FORWARD -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -m state --state RELATED -j ACCEPT iptables -A FORWARD -m state --state RELATED -j ACCEPT modprobe ip_conntrack_ftp [ .. snip creation and activation of custom chains .. ] * Setting up connection tracking for ACL lan iptables -A acl_lan -p tcp --tcp-flags RST RST -j log_lan iptables -A log_lan -p tcp --tcp-flags RST RST -j LOG \ --log-level debug --log-prefix '* DROP: Unexpected RST * ' ---- The last line intrigues me. We drop these packets since quite a while, but didn't log them until yesterday. It turns out that almost 15% of my firewall log now consists of packets qualifying as 'Unexpected RST' though. But... isn't the conntrack code at the beginning supposed to take care of accepting RSTs if they are associated with an active connection? Isn't a packet with RST that passes through the RELATED/ESTABLISHED match a packet that is not associated with an active connection and should thus be dropped? I'm a bit surprised to see this to say the least. It's not a subnet-wide portscan at least, the dropped packets definitely seem to indicate legitimate traffic. Thanks in advance for any hints, -- Martijn