Date: Sun, 09 May 2021 15:14:42 +0000 From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 255705] Routing does not honor mbuf_tag PACKET_TAG_IPFORWARD correctly Message-ID: <bug-255705-8303-P7AN4G7MQ2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-255705-8303@https.bugs.freebsd.org/bugzilla/> References: <bug-255705-8303@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255705 Lutz Donnerhacke <donner@FreeBSD.org> 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 <donner@FreeBSD.org> --- 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255705-8303-P7AN4G7MQ2>