From owner-freebsd-questions@freebsd.org Mon Aug 24 21:29:23 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D12C09C21C9; Mon, 24 Aug 2015 21:29:23 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69A392ED; Mon, 24 Aug 2015 21:29:23 +0000 (UTC) (envelope-from ascherrer@gmail.com) Received: by wicja10 with SMTP id ja10so83652475wic.1; Mon, 24 Aug 2015 14:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AjTIo/RuVxYQ4NppIh7+r2j7Gpycb0t/kjKLrOZQ680=; b=HOvdmbbnqEyLbfoT44ZUEm5mO3iaH7826QimeDbQ0QU93LTwaKsvH4AIgzjKVSn/nm ElEM0NQqoRZdtYHKzcpijsZmOcdsQEJcFqxztJ+XqddLv0GKFHlHJ5wlOPlj5qE3OLzS kOpfMfQlVhlRVh65BhgfiGpPciNo9ONNZsDm0/2e+Oek2weZKMaSib0KVPQCRy1oxONF 4UGBXOHT3dUmukPWYvBTY6YlQFL9vDFSfMtJqDdy2198bZtyCDu48t+fxio3OhfL164n kCSmG6gAXwuRhVmtSIcSUzcS6iPiMSBVBvfyIaPnhWEGnCbrsq7KL/DXjxvPDlVVl4/p Exaw== X-Received: by 10.194.77.244 with SMTP id v20mr46947178wjw.122.1440451761998; Mon, 24 Aug 2015 14:29:21 -0700 (PDT) Received: from manzana.hws.homeip.net ([2001:470:b71d:0:225:ff:fef2:447f]) by smtp.gmail.com with ESMTPSA id fk8sm5885700wib.22.2015.08.24.14.29.20 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Aug 2015 14:29:20 -0700 (PDT) Message-ID: <55DB8CAF.8040608@gmail.com> Date: Mon, 24 Aug 2015 23:29:19 +0200 From: andreas scherrer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-questions@freebsd.org CC: Ian Smith , freebsd-ipfw@freebsd.org Subject: Re: ipfw's "via" rule option/match pattern References: <20150821013137.E8515@sola.nimnet.asn.au> In-Reply-To: <20150821013137.E8515@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 21:29:24 -0000 > In freebsd-questions Digest, Vol 585, Issue 3, Message: 9 > On Wed, 19 Aug 2015 00:41:35 +0200 andreas scherrer wrote: > > When I run a quick test, sending one ICMP echo request from > > 192.168.32.10 to 192.168.38.17 (two devices communicating via the box > > that has the "count" rules listed below configured), I get the following > > result: > > A good set of tests for all combinations. Something else I saw recently > made me doubt that my own understanding of this was correct, and your > tests seem to confirm that I've been misadvising people for, oh, the > best part of 10 years .. here's the code, which I've checked hasn't > functionally changed at all since 2012, and little from 2002 with > Luigi's first ip_fw2.c (tabs lost): > > case O_RECV: > match = iface_match(m->m_pkthdr.rcvif, > (ipfw_insn_if *)cmd, chain, &tablearg); > break; > > case O_XMIT: > match = iface_match(oif, (ipfw_insn_if *)cmd, > chain, &tablearg); > break; > > case O_VIA: > match = iface_match(oif ? oif : > m->m_pkthdr.rcvif, (ipfw_insn_if *)cmd, > chain, &tablearg); > break; > > iface_match() (qv) does the test vs iface name or IP address, returning > 1 on a match, but begins by returning 0 if the passed interface is NULL. > In the case of O_VIA, if the outside iface is specified then that iface > (only) is tested; the rcvif is only checked if there's NO out iface. > > This directly contradicts what I've been telling myself and others for > years :( I guess what's amazing is that nobody who'd know better ever > pulled me up on such statements, increasing confidence in wrongness :) > > > ----- > > When 192.168.38.17 does not answer the ping: > > 00350 2 168 count icmp from 192.168.32.10 to 192.168.38.17 recv re0.32 > > 00350 0 0 count icmp from 192.168.38.17 to 192.168.32.10 recv re0.38 > > 00351 1 84 count icmp from 192.168.32.10 to 192.168.38.17 in recv re0.32 > > 00351 0 0 count icmp from 192.168.38.17 to 192.168.32.10 in recv re0.38 > > 00352 1 84 count icmp from 192.168.32.10 to 192.168.38.17 out recv re0.32 > > 00352 0 0 count icmp from 192.168.38.17 to 192.168.32.10 out recv re0.38 > > 00355 1 84 count icmp from 192.168.32.10 to 192.168.38.17 via re0.32 > > 00355 0 0 count icmp from 192.168.38.17 to 192.168.32.10 via re0.38 > > 00356 1 84 count icmp from 192.168.32.10 to 192.168.38.17 in via re0.32 > > 00356 0 0 count icmp from 192.168.38.17 to 192.168.32.10 in via re0.38 > > 00357 0 0 count icmp from 192.168.32.10 to 192.168.38.17 out via re0.32 > > 00357 0 0 count icmp from 192.168.38.17 to 192.168.32.10 out via re0.38 > > 00358 1 84 count icmp from 192.168.32.10 to 192.168.38.17 out recv re0.32 xmit re0.38 > > 00358 0 0 count icmp from 192.168.38.17 to 192.168.32.10 out recv re0.38 xmit re0.32 > > > > When 192.168.38.17 does answer the ping: > > 00350 2 168 count icmp from 192.168.32.10 to 192.168.38.17 recv re0.32 > > 00350 2 168 count icmp from 192.168.38.17 to 192.168.32.10 recv re0.38 > > 00351 1 84 count icmp from 192.168.32.10 to 192.168.38.17 in recv re0.32 > > 00351 1 84 count icmp from 192.168.38.17 to 192.168.32.10 in recv re0.38 > > 00352 1 84 count icmp from 192.168.32.10 to 192.168.38.17 out recv re0.32 > > 00352 1 84 count icmp from 192.168.38.17 to 192.168.32.10 out recv re0.38 > > 00355 1 84 count icmp from 192.168.32.10 to 192.168.38.17 via re0.32 > > 00355 1 84 count icmp from 192.168.38.17 to 192.168.32.10 via re0.38 > > 00356 1 84 count icmp from 192.168.32.10 to 192.168.38.17 in via re0.32 > > 00356 1 84 count icmp from 192.168.38.17 to 192.168.32.10 in via re0.38 > > 00357 0 0 count icmp from 192.168.32.10 to 192.168.38.17 out via re0.32 > > 00357 0 0 count icmp from 192.168.38.17 to 192.168.32.10 out via re0.38 > > 00358 1 84 count icmp from 192.168.32.10 to 192.168.38.17 out recv re0.32 xmit re0.38 > > 00358 1 84 count icmp from 192.168.38.17 to 192.168.32.10 out recv re0.38 xmit re0.32 > > ----- > > > > According to the statement in [4] I would expect rule 357 to match... > > Yes; [4] is clearly wrong in this respect. 'out via' does NOT check the > receive interface if the transmit interface is known. Thank you for your effort! I finally understand what I am doing here! Awesome! To be honest I was looking for the code you pasted but was not able to find it. Now I know where to look. In summary I think it would be reasonable to advise people to *not* use "via" in combination with "in" or "out". "in via $if" => "in recv $if" "out via $if" => "out xmit $if" Unless there can be outgoing packets without an xmit interface; but I don't see what those would be good for. Still looking for a use case for "via" (there must be a reason it exists, right?) "via" seems to make more sense when used *without* "in"/"out". "via $if" matches packets that are either incoming on $if or outgoing on $if. The most prominent use case that comes to my mind for that would be NAT (hiding an RFC 1918 network): nat X ip4 from any to any via $if Assuming the above is correct and that I wanted to tackle the issue of rewriting the ipfw handbook section: how would I do that (i.e. how to submit a new version)? Best regards andreas