From nobody Thu Dec 08 11:31:26 2022 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4NSX6R0cgQz4jDvL for ; Thu, 8 Dec 2022 11:31:27 +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 4NSX6Q5PgVz4N3V for ; Thu, 8 Dec 2022 11:31:26 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1670499086; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/CoTc917zjPFyhvOTfV97gDov5jRzLv/NMqpVtJfDWQ=; b=QVz7vf+2eCWEdtiMWDUMBQINp87aSzQwTXYofyoSQs1FT3uex77YBkIXWh9hqjCM7Uu0+S Pj9iCcMylhx5iMtqKqn+MqoWO6vBSzIXEJ6HOG3yPUG0PtwhsGZgtMPv5VipXT2QTygJnF 6KMNG2CzDVBX2mXMKInI+zwo9ltBkdekdPIAXylLsQbYl0DTqIB5SYZupiTBNQNa3lc3pe LdRWXTGgg8F2rNRCKAzP2Ux9qbB9DOTo62vAdQ1vZEwBJtFXa8RwnYXyKBizfwIkO76qVz tvZRhWI3moaVg+OdnnYGa2Sf/PqTryMUaB56facZX/gUjYNINMhDeE6NqUAsBQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1670499086; a=rsa-sha256; cv=none; b=dKc++RJdhbn6FX8iS7686QaKr2xttPryW68kXQEILDOsdLD0c6YL+7HXYm99Co5bOBdARe jzZAN5DBBwKtLdL2Wgx77rgysCrYR+g/YnpGFjYUggzntez/QGCuUK8bw/6e7GtGecfm7O +pe3IZ1DAmOTtpk/986wSoUsnqgTy4aKg4koZflJ4niSO5p7HSgxGffwZltXaROUjghz/I +su2qkFfvdRlN/wy7pou4n8AbRpOsCToPH1KdgOPbN5YWtMvEKsoMLm4XIBwzutBTFbBlg XHuHQqNJMybnQ4SYTBu+AyvUZUoRQhS5DP0o6HVJbRs40KTnd/0MIf4wwaFprg== 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 4NSX6Q4SpYztcs for ; Thu, 8 Dec 2022 11:31:26 +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 2B8BVQc8059157 for ; Thu, 8 Dec 2022 11:31:26 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 2B8BVQhj059156 for bugs@FreeBSD.org; Thu, 8 Dec 2022 11:31:26 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: bugs@FreeBSD.org Subject: [Bug 268241] broken handling of icmp needfrag packets with libalias/ipfw_nat and smaller wan mtu Date: Thu, 08 Dec 2022 11:31:26 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 13.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: john@sanren.ac.za X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D268241 Bug ID: 268241 Summary: broken handling of icmp needfrag packets with libalias/ipfw_nat and smaller wan mtu Product: Base System Version: 13.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: john@sanren.ac.za Created attachment 238625 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D238625&action= =3Dedit patch to make needfrag packets work with nat and an interface with a smaller mtu on the same device. When using ipfw + nat on the same device as the wan interface and the mtu of the wan interface is smaller than the default, the created needfrag packets= are not handled correctly. The problem is if a packet is received from the lan it will go through nat = and gets translated to use the ip address of the outgoing interface as source i= p. If it then tries to send it out, the output part of the stack will realize = that it is too big and create the needfrag icmp packet. It will use the source i= p as the destination and realize that is a local address and use 127.0.0.1 as the source address and route it on lo0. Currently libalias has no way to fix the source ip of 127.0.0.1. Using firewall rules like this: ##### wan=3D"vtnet0" lan=3D"vtnet1" ${fwcmd} nat 123 config if ${wan} log ${fwcmd} add 1000 count log all from any to any ${fwcmd} add 5000 nat 123 ip4 from any to any via ${wan} ${fwcmd} add 5050 nat 123 ip4 from any to not 127.0.0.1 via lo0 ${fwcmd} add 6000 allow log all from any to any ##### Results in the ipfw logs like this. (The client is 10.10.1.3, the wan interface/nat address is 10.10.2.2 and the test target is 10.10.5.5) ##### Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5 in via vtnet1 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.1.3 10.10.5.5 = in via vtnet1 Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:8.0 10.10.1.3 10.10.5.5 o= ut via vtnet0 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:8.0 10.10.2.2 10.10.5.5 = out via vtnet0 Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2 o= ut via lo0 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.2.2 = out via lo0 Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.2.2 in via lo0 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3 = in via lo0 Dec 7 14:17:31 rtr kernel: ipfw: 1000 Count ICMP:3.4 127.0.0.1 10.10.1.3 o= ut via vtnet1 Dec 7 14:17:31 rtr kernel: ipfw: 6000 Accept ICMP:3.4 127.0.0.1 10.10.1.3 = out via vtnet1 ###### I have made a patch to libalias/alias.c in IcmpAliasIn2() to check if the source ip is IN_LOOPBACK() and the destination is not IN_LOOPBACK() and then just copy the destination to the source address. There might be better ways= and it might be better to use the ip address of the outgoing interface as the source, but it did not seem easy to retrieve that from inside libalias. With this ping and ssh works as expected. Regards John --=20 You are receiving this mail because: You are the assignee for the bug.=