Firewall Wizards mailing list archives
New ftp behavior
From: Petri Virkkula <pvirkkul () iki fi>
Date: Mon, 27 Oct 1997 13:42:34 +0200
"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 ---
Current thread:
- New ftp behavior dharris (Oct 23)
- Re: New ftp behavior Jyri Kaljundi (Oct 24)
- <Possible follow-ups>
- Re: New ftp behavior arager (Oct 23)
- Re: New ftp behavior Wyllys Ingersoll (Oct 24)
- Re: New ftp behavior Vern Paxson (Oct 23)
- New ftp behavior Petri Virkkula (Oct 27)
- Re: New ftp behavior David Aylesworth (Oct 27)
- RE: New ftp behavior Safier, Adam (GEIS) (Oct 27)
- Re: New ftp behavior Bernd Eckenfels (Oct 30)