From nobody Tue Aug 30 16:11:45 2022 X-Original-To: freebsd-net@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 4MHC4L3pNJz4ZpWZ for ; Tue, 30 Aug 2022 16:12:02 +0000 (UTC) (envelope-from lutz@iks-jena.de) Received: from annwfn.iks-jena.de (annwfn.iks-jena.de [IPv6:2001:4bd8::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MHC4K4gvGz43j6 for ; Tue, 30 Aug 2022 16:12:01 +0000 (UTC) (envelope-from lutz@iks-jena.de) X-SMTP-Sender: IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f Received: from belenus.iks-jena.de (belenus.iks-jena.de [IPv6:2001:4bd8:0:666:248:54ff:fe12:ee3f]) by annwfn.iks-jena.de (8.15.2/8.15.2) with ESMTPS id 27UGBjCq013787 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 Aug 2022 18:11:46 +0200 X-MSA-Host: belenus.iks-jena.de Received: (from lutz@localhost) by belenus.iks-jena.de (8.14.3/8.14.1/Submit) id 27UGBj9L032346; Tue, 30 Aug 2022 18:11:45 +0200 Date: Tue, 30 Aug 2022 18:11:45 +0200 From: Lutz Donnerhacke To: tt78347 Cc: "freebsd-net@freebsd.org" Subject: Re: IPFW NAT intermittently fails to redirect UDP packets; seeking DTrace scripts or other advice Message-ID: <20220830161145.GA31694@belenus.iks-jena.de> References: List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) X-Rspamd-Queue-Id: 4MHC4K4gvGz43j6 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of lutz@iks-jena.de designates 2001:4bd8::19 as permitted sender) smtp.mailfrom=lutz@iks-jena.de X-Spamd-Result: default: False [-3.09 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.995]; FORGED_SENDER(0.30)[lutz@donnerhacke.de,lutz@iks-jena.de]; R_SPF_ALLOW(-0.20)[+ip6:2001:4bd8::/48]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_LOW(-0.10)[2001:4bd8:0:666:248:54ff:fe12:ee3f:received]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[protonmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; ASN(0.00)[asn:15725, ipnet:2001:4bd8::/29, country:DE]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[donnerhacke.de]; RCVD_TLS_LAST(0.00)[]; FROM_NEQ_ENVFROM(0.00)[lutz@donnerhacke.de,lutz@iks-jena.de] X-ThisMailContainsUnwantedMimeParts: N On Mon, Aug 29, 2022 at 06:36:26PM +0000, tt78347 wrote: > ipfw -q nat 1 config if $extif unreg_only reset \ > redirect_port udp 192.168.21.4:500 500 \ > redirect_port udp 192.168.21.4:4500 4500 > $add 450 nat 1 udp from any to any 500,4500 in via $extif > $add 451 nat 1 udp from any to any 500,4500 out via $extif > $add 500 nat 1 ip from any to any via $extif in > $add 65000 nat 1 ip from any to any via $extif out Only a quick look ... There is no guarantee, that the ports of the UDP packets are not modified by libalias (NAT is designed to do exactly this modification). So some of the matches seems to be a bit optimistic, > - This system has net.inet.ip.fw.one_pass=0 man ipfw To let the packet continue after being (de)aliased, set the sysctl variable net.inet.ip.fw.one_pass to 0. For more information about aliasing modes, refer to libalias(3). Hence the NAT is applied multiple times if the path through the rules is a bit unlucky. The traces show, that the problematic cases are those where the packets are not (de)aliased. This can be the case, when libalias has no more free ports available for aliasing. In such a case, the packet is returned unmodified (unaliased) with an error code. I'm not sure, if this will cause a packet drop or not, especially in the one_pass=0 case. It might be possible, that duplicate packets (or quickly repeated ones) trigger an unintended aliasing of the source port. This will create an flow in the NAT table which is handled before the port redirection. And it might miss the rules with explicit port numbers. But this will be probably the wrong idea.