From owner-freebsd-ipfw@FreeBSD.ORG Thu Mar 23 14:47:44 2006 Return-Path: X-Original-To: FreeBSD-ipfw@freebsd.org Delivered-To: FreeBSD-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8794C16A433 for ; Thu, 23 Mar 2006 14:47:44 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B039E43D58 for ; Thu, 23 Mar 2006 14:47:32 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k2NElHh1055107; Thu, 23 Mar 2006 16:47:17 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Thu, 23 Mar 2006 16:47:17 +0200 (EET) From: Dmitry Pryanishnikov To: Luigi Rizzo In-Reply-To: <20060323060006.A66681@xorpc.icir.org> Message-ID: <20060323162418.S45142@atlantis.atlantis.dp.ua> References: <20060323133729.D63213@atlantis.atlantis.dp.ua> <20060323060006.A66681@xorpc.icir.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD-ipfw@freebsd.org Subject: Re: IPFW1->2 regression: "in/out/via any" ignored X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2006 14:47:44 -0000 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