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>
index | next in thread | raw e-mail
>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:
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711141220.NAA04455>