Great Circle Associates Firewalls
(October 1997)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: New ftp behavior
From: Petri Virkkula <pvirkkul @ iki . fi>
Date: Mon, 27 Oct 1997 13:42:34 +0200
To: firewall-wizards @ nfr . net, firewalls @ GreatCircle . COM, dharris @ kcp . com
In-reply-to: <199710231620 . JAA13962 @ honor . greatcircle . com>
References: <199710231620 . JAA13962 @ honor . greatcircle . com>

>>>>> "Delmer" == dharris  <dharris @
 kcp .
 com> writes:

Delmer> What causes the remote site to behave this way?  It looks like
Delmer> the command portion of the ftp transaction is done with
Delmer> xxx.xxx.xxx.yyy while the data portion is done with
Delmer> xxx.xxx.xxx.zzz. Maybe this is done for load-sharing, 
Delmer> but it sure doesn't get past MY firewall.

	The email below might tell reason for this (ie. TCP/IP-stack
	NT bug), if the remote end was NT using virtual addressing.


	Petri

--- cut here ---
From: Dmitry Kohmanyuk <dk @
 GENESYSLAB .
 COM>
Sender: Windows NT BugTraq Mailing List <NTBUGTRAQ @
 LISTSERV .
 NTBUGTRAQ .
 COM>
To: NTBUGTRAQ @
 LISTSERV .
 NTBUGTRAQ .
 COM
Subject:      Re: FW: Bug in TCP/IP with multiple IP addresses assigned to one
              NIC
Date:         Fri, 10 Oct 1997 21:47:00 -0700
Reply-To: Dmitry Kohmanyuk <dk @
 GENESYSLAB .
 COM>

On Fri, Oct 10, 1997 at 04:54:28PM -0400, Adam Davis wrote:
> > When the server gets a packet, the from address reported by recvfrom()
> > will show the correct information.  Now echo the packet back to that
> > address.  The client program, when doing it's recvfrom(), will not
> > always show the same IP address in the from address.  It is supposed to
> > be the same IP address it made the original request to.  It will
> > actually be any one of the multiple IP addresses assigned to the server
> > machine which were in the same subnet on the same interface.

> >From MS Technet whitepaper:
> MS Windows NT 3.5, 3.51, 4.0 - TCP/IP Implementation Details
>
> When an IP datagram is sent from a multihomed host, it will be handed down to
> the interface card with the best apparent route to the destination.
> Accordingly, the datagram may bear the source IP address of one interface in
> the multihomed host, yet be placed on the media by a different NIC. The source
> MAC address on the frame will be that of the NIC that actually transmitted the
> frame onto the media, and the source IP address will be the one that the
> sending application sourced it from, not necessarily one of those associated
> with the sending NIC in the configuration screens in Network Control Panel.

There is a difference between multi-homed host with several interfaces (each
with its own address) and several addresses on one interface (this is what
original poster was talking about - `Advanced' panel in TCP/IP interface properties.)

In first case, it is perfectly legal for reply packet (TCP or UDP) to exit
multi-homed host via different interface (according to routing tables), thus
bearing appropriate MAC address and still have IP address the original packet
was sent to.  In fact, this is only correct behaviour, and NT does this right.

What NT does _NOT_ get right, and what was the subject of quoted message,
is that if you have _several_ addresses on *one* interface (so-called virtual
addresses, i.e., for web hosting), the packets sent can have first IP address
on the interface instead of the address the packet was sent to.

We came across this issue when connecting to multi-homed FTP server on NT:
the FTP server address was configured as secondary address, and control
connection packets are sent from this address, but data connection packets
are sent from the primary address.

This can be a different from the situation described by original poster, though.

--- cut here ---


References:
Indexed By Date Previous: Re: Unlimited Users Firewalls
From: Bernd Eckenfels <lists @ lina . inka . de>
Next: SCO how secure ?
From: "Norman Widders" <winspace @ geko . net . au>
Indexed By Thread Previous: New ftp behavior
From: dharris @ kcp . com
Next: Re: New ftp behavior
From: Aleph One <aleph1 @ dfw . net>

Google
 
Search Internet Search www.greatcircle.com