From mboxrd@z Thu Jan 1 00:00:00 1970 From: "U.Mutlu" Subject: Re: [iptables] Effect of negating multiple source or dest IPs (-s or -d) Date: Tue, 08 Nov 2011 22:59:37 +0100 Message-ID: References: Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: netfilter-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: netfilter@vger.kernel.org Jozsef Kadlecsik wrote, On 2011-11-08 21:22: > On Tue, 8 Nov 2011, U.Mutlu wrote: > >> Jan Engelhardt wrote, On 2011-11-08 17:44: >>> On Tuesday 2011-11-08 17:19, U.Mutlu wrote: >>> >>>> sim@netmess.org wrote, On 2011-11-08 17:16: >>>>>> What's the effect of this rule on a multihomed box >>>>>> (the IPs below are just some examples, not real): >>>>>> >>>>>> iptables -A INPUT ! -d 1.2.3.4,2.3.4.5 -p all -j DROP >>>>>> >>>>> >>>>> the newest version of iptables says: >>>>> >>>>> iptables v1.4.12.1: ! not allowed with multiple source or destination IP >>>>> addresses >>>> >>>> Oh, one wonders why they did so... >>> >>> Because it leads to a confusing result. >>> >>> ! -d a,b,c >>> >>> could be reasonably interpreted as >>> >>> ! -d a&& ! -d b&& ! -d c >>> >>> but because using "," in -s/-d means a simple rule expansion, it >>> actually generates an equivalent of >>> >>> ! -d a || ! -d b || ! -d c >> >> But OR'ing them IMHO doesn't make much sense, just think about it. >> I would suggest to AND them. >> Look, a normal rule like this one >> iptables -A INPUT -m state --state NEW -p tcp --dport 80 -j ACCEPT >> matches only if every single part of it matches (ie. AND). >> Then in our negation case above it should behave similar, >> and not switch to OR. > > The matches are AND-ed. However the individual matches may generate OR > conditions, like multiport. > > What you suggest means that while > > -d a,b > > is interpreted as "a" OR "b", then > > ! -d a,b > > should be interpeted as NOT "a" AND NOT "b". > > I think that'd be pretty confusing. My problem was this: my eth0 has to accept packets for 2 IPs, but then I saw that there comes in also much other unwanted garbage like broadcast and multicast, so I wanted right in the beginning of my script DROP all packets not destined to the 2 IP. Ok, I think as an alternative I can realize this with an own chain and with 'convential' methods. Too bad, I just wanted avoid that extra work of restructuring my script... :-)