One other comment on this subject...

If the control connection came through a firewall or load balancer that is
FTP-aware (as most are these days), when the FTP server returns the PASV
response to the client, the firewall will see that it contains a local
address (e.g. and rewrite it with an external address. So,
assuming you have a firewall or load balancer that has been configured
properly for FTP, you may not have to explicitly configure the FTP server
with an external address.

An exception is SSL/TLS: Since the control connection is encrypted, the
firewall cannot eavesdrop on the protocol conversation. To handle this case
there is really no choice but to explicitly tell the FTP server what
external address to return to the client in response to the PASV command.
That's the purpose of

One solution to the SSL/TLS problem would be for the FTP server to handle
the CCC command. An FTP client can send this command to the server to drop
out of secure mode long enough to send the PASV command, giving the firewall
an opportunity to rewrite the response with the correct address. The client
can then send the AUTH/SSL or AUTH/TLS sequence to return to secure mode. I
don't know if there are plans for Apache FTP to implement CCC, but it would
be a nice enhancement.


On 10/20/07 4:35 AM, "Niklas Gustavsson" <[EMAIL PROTECTED]> wrote:

> Atul Gohad wrote:
>> Hello,
>> Have a couple of questions here:
>> 1. What is the mode in which normally FTP clients are supposed to connect (
>> Active / Passive )?
>>     Whats the default / recommended mode of operation?
> When FTP was defined, Active mode was the normal. However, with the
> current frequent use of firewalls, passive is a better choice.
> Most clients in my experience still have active as the default.
>> 2. There is a property setting of
>> Apache FTP Server.
>> What is the significance of this property and what should be the value
>> provided for this? Should it be pointing to the ip address of the system
>> where the FTP server is running? I found this property some what related (
>> guessing by the name, and in the Server logs, it shows opening a passive
>> port connection on this ip with a random/ self generated port ). But not
>> sure if this configuration has something to do with the problem I see.
> When the client tells the server that it wants to use passive mode (by
> sending the PASV commands), the server needs to tell the client where it
> should open the data connection (IP and port). Now, if the server is
> placed behind a NAT, the IP of the server box might not work for the
> client. Thus, this configuration tells the server to return that IP
> instead so that the client can connect via the NAT.
> You problem sounds like it could be as simple as a firewall on the
> Redhat box getting in the way.
> Hope that helps!
> /niklas

Reply via email to