From owner-freebsd-net@freebsd.org Mon Apr 30 18:03:11 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02C07FB2346 for ; Mon, 30 Apr 2018 18:03:11 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (unknown [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7C51D7CA98 for ; Mon, 30 Apr 2018 18:03:10 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id w3UI33ke088608 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Apr 2018 20:03:04 +0200 (CEST) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: freebsd@wagsky.com Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id w3UI30DS049391 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 1 May 2018 01:03:00 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: ipfw -- selecting locally generated packets To: Jeff Kletsky , freebsd-net@freebsd.org References: <979d3478-4bec-e6a1-41cd-bb26beb93123@wagsky.com> From: Eugene Grosbein Message-ID: <5AE75A4E.6020907@grosbein.net> Date: Tue, 1 May 2018 01:02:54 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <979d3478-4bec-e6a1-41cd-bb26beb93123@wagsky.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -0.0 SPF_PASS SPF: sender matches SPF record * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2018 18:03:11 -0000 01.05.2018 0:48, Jeff Kletsky wrote: > From time to time, I rewrite my firewall rules to take advantages of the ever-improving set of features that ipfw provides. One of the challenges I have faced in the past was selecting packets that are generated on the firewall host itself, as opposed to those that it received through an interface. > > While I find most of the Linux firewall implementations untenable for a variety of reasons, it does provide differentiation between what they call "OUTPUT" and "FORWARD". I'm looking to see if there is a "better" way to implement this kind of selection with the 11.1 version of ipfw. > > "out and not in" may years ago seemed an obvious selector, and it's good to see that it is now clearly documented that it doesn't work in "man ipfw" with "(in fact, out is implemented as not in)". > > "not recv any" doesn't seem to be helpful either > > $ sudo ipfw add 64000 count ip from any to any out xmit any not recv any > 64000 count ip from any to any out > > In the past, I've tagged all incoming packets and used that tag to differentiate between the two. > > Is there something "cleaner" (or perhaps clearer) that using a tag in that way? I have been using "from me" for years and it works. If you have NAT, process "from me" packets before translating outgoing packets and process "to me" after translating incoming packets.