Date: Fri, 14 Nov 1997 13:20:39 +0100 (MET) From: Charlie Root <root@sniff.utimaco.co.at> To: FreeBSD-gnats-submit@FreeBSD.ORG Subject: bin/5041: bug in natd Message-ID: <199711141220.NAA04455@sniff.utimaco.co.at> Resent-Message-ID: <199711141330.FAA27960@hub.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 5041 >Category: bin >Synopsis: natd drops aliases >Confidential: no >Severity: serious >Priority: high >Responsible: freebsd-bugs >State: open >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Nov 14 05:30:00 PST 1997 >Last-Modified: >Originator: Christian Gusenbauer, Michael Schuster >Organization: >Release: FreeBSD 3.0-CURRENT i386 >Environment: 3.0 current as of 10-26-97 >Description: First, our network setup: "inside" "outside" +------+ +------+ +------+ | B 1 ---------------- 2 FW 3 ---------------- 4 A | +------+ +------+ +------+ IP # for Interface 1: 10.0.1.90; per alias (NAT) on FW 195.96.28.165 Interface 2: 10.0.1.254 Interface 3: 195.96.28.163 Interface 4: 195.96.28.167 FW is a FreeBSD machine running NAT (3.0 current), A and B are arbitrary machines, in our case Windows NT. We call natd with the addresses as commandline parameters. We're seeing the following symptoms: (We're talking about ICMP packets here) Ping A -> B: src:195.96.28.167 -> dest 195.96.28.165 (the alias) FW receives on 3: src:195.96.28.167 -> dest 195.96.28.165 FW sends on 2: src:195.96.28.167 -> dest 10.0.1.90 Reply: B sends: src 10.0.1.90 -> dest 195.96.28.167 FW receives on 2: src 10.0.1.90 -> dest 195.96.28.167 FW sends on 3: src 195.96.28.165 -> dest 195.96.28.167 OK Ping B -> A: B sends src 10.0.1.90 -> dest 195.96.28.167 FW receives on 2: src 10.0.1.90 -> dest 195.96.28.167 FW sends on 3: src 195.96.28.163 -> dest 195.96.28.167 ^^^ Reply: A sends src 195.96.28.167 -> dest 195.96.28.163 ^^^ FW receives on 3: src 195.96.28.167 -> dest 195.96.28.163 FW sends on 2: src 195.96.28.167 -> dest 10.0.1.90 which is in fact NOT OK (according to man-page libalias.3). Obviously, something is wrong with the mapping of addresses. We managed to trace this behaviour to the fact that after the addresses have been entered in the resp. tables, they are immediately deleted. We think the reason for this is that ParseArgs() (which via ParseOption() and SetupAddressRedirect() calls PacketAliasRedirectAddr()) is called BEFORE PacketAliasSetAddress() in natd.c. PacketAliasSetAddress() clears all alias data, and - voila - there goes our Address Translation Information (ATI(r)). We hacked a fix by avoiding to set PKT_ALIAS_RESET_ON_ADDR_CHANGE in PacketAliasInit(), which had the rather unpleasant side effect that there's no default alias any more. >How-To-Repeat: start natd with the following options: natd -n ed0 -redirect_address 10.0.1.90 195.96.28.165 -v >Fix: not available >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711141220.NAA04455>