From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E8E531381FB for ; Thu, 27 Dec 2012 11:30:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0BEE921C1D6; Thu, 27 Dec 2012 11:29:52 +0000 (UTC) Received: from einstein.gmurray.org.uk (einstein.gmurray.org.uk [81.2.114.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BD45321C1CA for ; Thu, 27 Dec 2012 11:28:17 +0000 (UTC) Received: from einstein.gmurray.org.uk (einstein.gmurray.org.uk [IPv6:::1]) by einstein.gmurray.org.uk (8.14.5/8.14.5) with ESMTP id qBRBSFvq013644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 27 Dec 2012 11:28:15 GMT DKIM-Filter: OpenDKIM Filter v2.7.1 einstein.gmurray.org.uk qBRBSFvq013644 Authentication-Results: einstein.gmurray.org.uk; dkim=none reason="no signature"; dkim-adsp=none; dkim-atps=neutral From: Graham Murray To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] IPTABLES syntax change? References: <20121227004732.GB5854@waltdnes.org> <50DBA7D0.4060800@orlitzky.com> Date: Thu, 27 Dec 2012 11:28:15 +0000 In-Reply-To: <50DBA7D0.4060800@orlitzky.com> (Michael Orlitzky's message of "Wed, 26 Dec 2012 20:43:44 -0500") Message-ID: <87zk0zivjk.fsf@einstein.gmurray.org.uk> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.6 at einstein X-Virus-Status: Clean X-SPF-Scan-By: smf-spf v2.0.2 - http://smfs.sf.net/ Received-SPF: None (einstein.gmurray.org.uk: domain of graham@gmurray.org.uk does not designate permitted sender hosts) receiver=einstein.gmurray.org.uk; client-ip=::1; envelope-from=; helo=einstein.gmurray.org.uk; X-Archives-Salt: 6b4f66ca-ed2e-46c2-b024-3c1eb302bfe4 X-Archives-Hash: 78723c9ab63e15d84afe149889c9897a Michael Orlitzky writes: > The 'conntrack' module is supposed to be a superset of 'state', so most > things should be compatible. You really have two warnings there; the > first is for the state -> conntrack switch, and the second is because > you're missing the --state flag in your rules. > > In your example, you turn on the state matching, > > iptables -A TCP_IN -p tcp -m state -m tcp -j UNSOLICITED > > but you don't specify *which* state(s) you want to match. It wants you > to specify --state SOMETHING. I'd guess that it used to interpret "no > state" as "any state." The problem is not really the OP's fault. The problem is that if you have tables with the form "-m state --state XXX" at the point you upgrade, iptables-save (quite possibly called automatically by /etc/init.d/iptables stop) will save it as "-m state --state" - ie 'forgetting' which state(s) the rule applies to. The solution is to either change all your rules to use "-m conntrack --ctstate XXX" before upgrading or editing /var/lib/iptables/rules-save to globally replace '-m state' by '-m conntrack' and '--state' by '--ctstate' prior to the upgrade and (at least temporarily) edit /etc/conf.d/iptables to set SAVE_ON_STOP="no". The same will also need to be done with ip6tables if you use that. I think that this is a serious enough change in behaviour that an elog warning should have been issued.