From owner-freebsd-ipfw@FreeBSD.ORG Wed Jan 14 14:30:53 2004 Return-Path: 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 BB5D316A4CE for ; Wed, 14 Jan 2004 14:30:53 -0800 (PST) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3650543D62 for ; Wed, 14 Jan 2004 14:30:52 -0800 (PST) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id 909975F103; Wed, 14 Jan 2004 23:42:14 +0100 (CET) Date: Wed, 14 Jan 2004 23:42:14 +0100 From: Pawel Malachowski To: Sten Daniel S?rsdal Message-ID: <20040114224214.GB72981@shellma.zin.lublin.pl> References: <0AF1BBDF1218F14E9B4CCE414744E70F5D9779@exchange.wanglobal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0AF1BBDF1218F14E9B4CCE414744E70F5D9779@exchange.wanglobal.net> User-Agent: Mutt/1.4.1i cc: Luigi Rizzo cc: ipfw@freebsd.org Subject: Re: semantics of 'not-applicable' options in ipfw ? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jan 2004 22:30:53 -0000 On Wed, Jan 14, 2004 at 06:04:45PM +0100, Sten Daniel S?rsdal wrote: > I also believe that "via" option also causes the same kind of confussion. Going offtopic, but... That's true, people have problems with `via', it is a common practice to construct not-to-specific rules and to send packets via dummynet pipe twice, for example. ;) It is explained in ipfw(8), but not so clear for newbies. I personally prefer `in recv' and `out xmit' only, to make rulesets clear. Also lots of howtos and natd(8) uses `via' in examples with divert/natd. That's not good cause when someone is trying to work with both natd and dummynet, classifying packets on per-private-IP basis on exteral interface, it is better to split divert rule in the following manner: ipfw add divert natd ip from any to PUBLIC-IP-FOR-NAT[1] in recv NIC //now we have access to PRIVATE IPs for incoming packets and we can shape traffic on per-local-user basis //we also have access to PRIVATE IPs for outgoing packets since they were not passed throug natd ipfw add (dummynet rules here) ipfw add divert natd ip from PRIVATE-NET[1] to any out xmit NIC [1] Using PUBLIC-IP-FOR-NAT explicitly rather than `all' is better, because we avoid sending to divert socket packets destinated for other, public IP addressess in our LAN. Using PRIVATE-NET explicitly is better, because we avoid sending to divert socket packets from public IP addresses from our LAN. While we are near confussions, I know `queue' keyword is problematic for newbie dummynet users, because it has two different meanings, pipe has its queue and queue has its queue, also bunch of queues can be assigned with pipe, etc. ;) I usually explain newbies pipe as pipe, queue as queue ;) and queue (KB/slots) as a `buffersize'. It is also not clear in ipfw(8) what are these `slots', guessing just `packets', and what are advanteges or disadvanteges of using `slots' or `KB' unit. > By the way, do you have any plans to implement a tag/flag system? > ( example: > 100 flag 100 src-port 100 > 200 allow flag 100 > ) Someone may find it useful, especially with some kind of `skipto 0' available. ;) -- Paweł Małachowski