From owner-freebsd-net@freebsd.org Sun May 9 15:14:43 2021 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 3BDFD63A4A6 for ; Sun, 9 May 2021 15:14:43 +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 4FdSQp3rfzz3MgM for ; Sun, 9 May 2021 15:14:42 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 81E9863A3E8; Sun, 9 May 2021 15:14:42 +0000 (UTC) Delivered-To: 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 81B1F63A254 for ; Sun, 9 May 2021 15:14:42 +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 4FdSQp0Pxnz3Mjj for ; Sun, 9 May 2021 15:14:42 +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 F14FB13F24 for ; Sun, 9 May 2021 15:14:41 +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 149FEfMV099113 for ; Sun, 9 May 2021 15:14:41 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 149FEf2N099112 for net@FreeBSD.org; Sun, 9 May 2021 15:14:41 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: net@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: AssignedTo 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-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2021 15:14:43 -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 the assignee for the bug.=