Date: Tue, 30 Aug 2022 18:11:45 +0200 From: Lutz Donnerhacke <lutz@donnerhacke.de> To: tt78347 <tt78347@protonmail.com> Cc: "freebsd-net@freebsd.org" <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> In-Reply-To: <gg17I_Npe7ROH1jMb1q1NImxP-WeYJ1Onu-QT6OKzybIsUP1GLxQyhTqHXO6rqTSJlI9t776Kb_cfCdps8xH5aaSWxTerm8MCaG2qb0i770=@protonmail.com> References: <gg17I_Npe7ROH1jMb1q1NImxP-WeYJ1Onu-QT6OKzybIsUP1GLxQyhTqHXO6rqTSJlI9t776Kb_cfCdps8xH5aaSWxTerm8MCaG2qb0i770=@protonmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220830161145.GA31694>