From owner-freebsd-ipfw@freebsd.org Sun May 9 15:14:44 2021 Return-Path: Delivered-To: freebsd-ipfw@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 8A4A363A322 for ; Sun, 9 May 2021 15:14:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4FdSQq6nKDz3MXL for ; Sun, 9 May 2021 15:14:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E8C8F63A321; Sun, 9 May 2021 15:14:43 +0000 (UTC) Delivered-To: ipfw@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 E88CC63A4A8 for ; Sun, 9 May 2021 15:14:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FdSQq2Nhvz3MP1 for ; Sun, 9 May 2021 15:14:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4146913FAA for ; Sun, 9 May 2021 15:14:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 149FEhME099133 for ; Sun, 9 May 2021 15:14:43 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 149FEheW099132 for ipfw@FreeBSD.org; Sun, 9 May 2021 15:14:43 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 255705] Routing does not honor mbuf_tag PACKET_TAG_IPFORWARD correctly Date: Sun, 09 May 2021 15:14:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: donner@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2021 15:14:44 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255705 Lutz Donnerhacke changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|donner@FreeBSD.org |net@FreeBSD.org Summary|Is 'ipfw fwd' completely |Routing does not honor |broken now? |mbuf_tag | |PACKET_TAG_IPFORWARD | |correctly --- Comment #4 from Lutz Donnerhacke --- First let me quote the man page of ipfw(8). I verfied, that this descripti= on matches the behavior of the source code in branch "main". ----8/---- If ipaddr is a local address, then matching packets will be forwarded to po= rt (or the port number in the packet if one is not specified in the rule) on t= he local machine. If ipaddr is not a local address, then the port number (if specified) is ignored, and the packet will be forwarded to the remote address, using the route as found in the local routing table for that IP. The fwd action does not change the contents of the packet at all. In particular, the destination address remains unmodified, so packets forwarde= d to another system will usually be rejected by that system unless there is a matching rule on that system to capture them. For packets forwarded locall= y, the local address of the socket will be set to the original destination add= ress of the packet. This makes the netstat(1) entry look rather weird but is intended for use with transparent proxy servers. ----8/---- Now let's have a look at your rules. PING 5.5.5.5 does not match the ipfw rule set, does not match a specific ro= ute, and is forwarded to the default gateway. This gateway rejects the the pack= et, which is documented in your example. PING 8.8.8.8 does match your ipfw table(8) rule, hence the packet is send to the next hop 169.254.1.1. 169.254.1.1 is in your routing table and will use the next hop 192.168.68.1, which is your Internet gateway. So the unmodifi= ed packet is send to your Internet gateway, travel all the way through the net, will be reach the Google server, will get a response. This response is documented in your example. PING 8.8.4.4 does match your ipfw rule #9, hence the packet is send to the = next hop 169.254.1.1. 169.254.1.1 is in your routing table and will use the next hop 192.168.68.1, which is your Internet gateway. So the unmodified packet= is send to your Internet gateway, travel all the way through the net, will be reach the Google server, will get a response. This response is documented = in your example. PING 1.1.1.1 does match your ipfw rule #10, hence the packet is send to the next hop 192.168.68.1, which is your Internet gateway. So the unmodified packet is send to your Internet gateway, travel all the way through the net, will be reach the Google server, will get a response. This response is documented in your example. So far for anything up to 11.2. Your traceroute shows that on 13.0 all packets are send to the default gate= way regardless of the specified next_hop attribute (mbuf_tag =3D PACKET_TAG_IPFORWARD), as set by the ipfw processing. Hence this problem is a routing problem and not an ipfw problem. I'll reclassify the bug report. --=20 You are receiving this mail because: You are on the CC list for the bug.=