Date: Thu, 23 Mar 2006 16:47:17 +0200 (EET) From: Dmitry Pryanishnikov <dmitry@atlantis.dp.ua> To: Luigi Rizzo <rizzo@icir.org> Cc: FreeBSD-ipfw@freebsd.org Subject: Re: IPFW1->2 regression: "in/out/via any" ignored Message-ID: <20060323162418.S45142@atlantis.atlantis.dp.ua> In-Reply-To: <20060323060006.A66681@xorpc.icir.org> References: <20060323133729.D63213@atlantis.atlantis.dp.ua> <20060323060006.A66681@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello! On Thu, 23 Mar 2006, Luigi Rizzo wrote: >> Matches packets received, transmitted or going through, respec- >> tively, the interface specified by exact name (ifX), by device >> name (if*), by IP address, or through some interface. >> ...........................................^^^^^^^^^^^^^^^^^^^^^^ >> >> A packet may not have a receive or transmit interface: packets >> originating from the local host have no receive interface, while >> packets destined for the local host have no transmit interface. > > The second part of this paragraph is surely incorrect - there is no transmit > interface for packets in the inbound path (i.e. while they are in ip_input()) > whether or not they are destined locally. So 'xmit any' does not make > any sense. Of course, I'm talking about 'out' direction. I am used to write rules like following: count all from any to 192.168.1.0/24 out recv $ext_if xmit any here 192.168.1.1 is my gateway towards client subnet. My intent is clear: I don't want traffic to 192.168.1.1 which came via $ext_if to be counted here. Now I see that traffic for 192.168.1.1 won't reach this rule at all (so I suppose that it doesn't travel via ip_output at all). So yes, you're right about 'xmit any' - it indeed doesn't make any sense. > For locally generated packets i admit 'recv any' may be of some use, > and this is unsupported. There are probably workaround such as 'src-ip me' Oops! How can one know that feature which is documented from the beginning, which worked in ipfw1 - became 'unsupported' in ipfw2? It's clearly a regression to me, given that I can't use ipfw1 with modern RELENGs. > which may be of some help here although this particular instruction > can be expensive as it has to scan the list of local addresses. I don't understand that part. Given that 'out recv ifx' still works, we have incoming interface name for every transit outgoing packet. I'm sure there is some indication in this field that clearly says: "packet _is_ locally-generated". Isn't it? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060323162418.S45142>