I've seen something similar happen when overloading IP addresses on the
same machine interface. The system will accept incoming packets on
either IP address but the reply packet is from the first (top) IP
address in the routing table. This happens even if you have yyy and zzz
on different subnets and overload the IP address on the gateway and make
sure subnets match - the traffic originating on the server still goes
out the first address in the stack. Best to get rid of the IP
overloading on the server. You can also try to set a different priority
on each IP subnet and aim them at different gateways.
This is different from the problem where the FTP command connection is
on one IP/port connection while FTP data is on another IP/Port pair. A
poorly designed load balancing cluster might also be the culprit. PASV
might help this, if it's supported. A more common FTP implementation
from the server/cluster would be preferable or you can manually open
ports on the firewall. With a stateful inspection firewall with a
command language (FW-1) you could also try to code your own stateful FTP
rule (my least favorite solution.)
Adam
---------------
Adam Safier, Network Engineering Security Consultant
GE Information Services, Inc.
401 North Washington St., Rockville, Md. 20850
Ph: 301-340-5737 Internal: 8*273-5737 Fax: 301-340-4005
Adam .
Safier @
geis .
ge .
com http://www.geis.com
I'm proud to live in a country where I can express my personal opinions.
The opinions above may not be shared by my employer.
---------------
> -----Original Message-----
> From: dharris @
kcp .
com [SMTP:dharris @
kcp .
com]
> Sent: Thursday, October 23, 1997 12:18 PM
> To: mbloomer @
kcp .
com; sralstin @
kcp .
com; firewall-wizards @
nfr .
net;
> firewalls @
GreatCircle .
COM
> Cc: cbailey @
kcp .
com; dmchugh @
kcp .
com
> Subject: New ftp behavior
>
> This one is new to me so I don't know what to do about it.
>
> I had a customer trying to use Netscape Navigator to download a file
> through an ftp:// URL on a Web page at a vendor site. They received
> the
> error
>
> FTP File Transfer Failed: The FTP request could not be completed
> because
> the server is responding in an insecure manner.
>
> I checked the logs and discovered that, although the original ftp
> connection was made to xxx.xxx.xxx.yyy, the response was coming from
> xxx.xxx.xxx.zzz. The firewall very properly considered this an
> attempt to
> hijack an open port and closed the ftp transaction.
>
> What causes the remote site to behave this way? It looks like the
> command
> portion of the ftp transaction is done with xxx.xxx.xxx.yyy while the
> data
> portion is done with xxx.xxx.xxx.zzz. Maybe this is done for
> load-sharing,
> but it sure doesn't get past MY firewall.
>
> Delmer
Follow-Ups:
|
|
