From nobody Tue May 18 22:10:02 2021 X-Original-To: ipfw@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 18E465CEE74 for ; Tue, 18 May 2021 22:10:03 +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 4Fl9Cv07skz4SW5 for ; Tue, 18 May 2021 22:10:03 +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 E1C4F2735A for ; Tue, 18 May 2021 22:10:02 +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 14IMA2ho044753 for ; Tue, 18 May 2021 22:10:02 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 14IMA2qN044752 for ipfw@FreeBSD.org; Tue, 18 May 2021 22:10:02 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 255928] ipfw: nat64 not working on 13.0-RELEASE Date: Tue, 18 May 2021 22:10:02 +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: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: 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 List-Id: IPFW Technical Discussions List-Archive: https://lists.freebsd.org/archives/freebsd-ipfw List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ipfw@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255928 --- Comment #3 from Andrey V. Elsukov --- (In reply to PaulC from comment #0) According your dump I think what was happened are: > 16:34:03.718627 IP6 2001:470:1d41:1::55 > 64:ff9b::101:101: ICMP6, echo r= equest, seq 0, length 16 This entry generated by rule 1100 for outbound ICMPv6 echo request. > 16:34:03.718654 IP6 2001:470:1d41:1::55 > 64:ff9b::101:101: ICMP6, echo r= equest, seq 0, length 16 Then packet was routed to lo0 due to static route, and this entry was gener= ated by rule 700 as inbound packet. It was translated by NAT64 and directly put to outbound interface. > 16:34:03.718681 IP 192.168.1.55 > 1.1.1.1: ICMP echo request, id 1024, se= q 0, length 16 I'm not sure how this entry was created. Probably you have some strange IPv4 routing and somehow you have extra firewall check, and this was created by rule 1000 as inbound packet. Thus dynamic state was created. This also means that the packet was handled by ip_input and then passed to ip_tryforward. And this is "inbound" pass from ip_tryforward.=20 > 16:34:03.718684 IP 192.168.1.55 > 1.1.1.1: ICMP echo request, id 1024, se= q 0, length 16 This entry was created by the "outbound" firewall pass from ip_tryforward. = And translated packet finally gone to the destination. > 16:34:03.718757 IP 127.0.0.1 > 192.168.1.55: ICMP redirect 1.1.1.1 to hos= t 0.0.0.0, length 44 Since net.inet.ip.redirect is enabled by default, and mbuf's rcvif matches interfice given by route, you have ICMP redirect. And this entry was create= d by rule 1100 by firewall pass from icmp_error->ip_output. > 16:34:03.718762 IP 127.0.0.1 > 192.168.1.55: ICMP redirect 1.1.1.1 to hos= t 0.0.0.0, length 44 This entry probably was created by rule 900 and since ICMP redirect was not translated, it counted as unsupported protocol in NAT64. > 16:34:03.738308 IP 1.1.1.1 > 192.168.1.55: ICMP echo reply, id 1024, seq = 0, length 16 This entry was created by rule 100 as reverse match from the dynamic state created before, so it did not hit NAT64 to be translated back into IPv6. If you are 100% sure that exactly this configuration worked before 13.0, I = add melifaro@ to CC list, he did major routing rewriting in 13.0. Also, please provide what you have in `netstat -rn`. Also show `sysctl net.inet.ip | egrep "forward|redir"`. Also, you can create ipfwlog0 interface and see what will report NAT64 instance. --=20 You are receiving this mail because: You are the assignee for the bug.=