[Bug 255705] Routing does not honor mbuf_tag PACKET_TAG_IPFORWARD correctly

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255705

Lutz Donnerhacke <donner at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|donner at FreeBSD.org          |net at 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 at FreeBSD.org> ---
First let me quote the man page of ipfw(8).  I verfied, that this description
matches the behavior of the source code in branch "main".
----8/----
If ipaddr is a local address, then matching packets will be forwarded to port
(or the port number in the packet if one is not specified in the rule) on the
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 forwarded 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 locally,
the local address of the socket will be set to the original destination address
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 route,
and is forwarded to the default gateway.  This gateway rejects the the packet,
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 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 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 gateway
regardless of the specified next_hop attribute (mbuf_tag =
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.