From owner-freebsd-net@freebsd.org Sat Aug 24 23:21:26 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D062CCE5EB for ; Sat, 24 Aug 2019 23:21:26 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::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 46GDmP6vNvz4HNV for ; Sat, 24 Aug 2019 23:21:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7ONLH2e016365 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 24 Aug 2019 23:21:21 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: yuri@rawbw.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 x7ONL88L053348 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 25 Aug 2019 06:21:08 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Trying to understand why the ipfw rules don't work on lo0 To: Yuri , "freebsd-net@freebsd.org" References: From: Eugene Grosbein Message-ID: <7b71d9a2-a565-96f2-898a-4ab215a708a4@grosbein.net> Date: Sun, 25 Aug 2019 06:21:00 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46GDmP6vNvz4HNV X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.44 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; IP_SCORE(-1.36)[ip: (-3.00), ipnet: 2a01:4f8::/29(-1.96), asn: 24940(-1.85), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 23:21:26 -0000 25.08.2019 5:03, Yuri wrote: > I'm forwarding TCP connections coming to me on a particular port to the other interface. > It works fine when the connection originates from the outside host. > It doesn't work when the connection originates from my own host. > The description is here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239590 > Connections originating from my own host are automatically made on lo0, > and the same ipfw rule that works on the physical network interface doesn't work on lo0. > Is this a bug, or am I doing something wrong? Would you kindly ask questions of this type here first and leave Bugzilla for real bugs please? As for your question, you should make habit of using "log" keyword while debugging ipfw-related problems, for example: ipfw add 19001 nat 19001 log tcp from 192.168.5.3 to 192.168.5.3 3100 in recv lo0 This will write useful details to /var/log/security when a packet is matched by the rule. It will not add there anything if there are no matches. And if there are no matches and parameters are right, this generally means that packet is matched and consumed with some rule above. I presume your ruleset contains default rule "100 allow ip from any to any via lo0" that matches all local packets, so they have no change to hit your rule. Try changing 19001 to 90 so it catches packets earlier. If this does not help, show your full ruleset.