FTP problem with data connection

Some of our users have problem with the data connection using our ftp
services. They can login fine to the ftp servers but get "Getting file
list - timout" and similar errors when starting the data connections.

Our environment is:
FIREWALL: Linux box with Debian Woody and LDirectorD for the port
redirection to our servers on the inside. Port 20 and 21 are fully
open as far as we can see.
FTP SERVERS: One Windows 2000 server and another with Linux (same
problem connecting to both so probably the problem has to do with the
Firewall)

It does work fine from many clients out there but too many clients do
have problems. It would be easy to blame the client computer for bad
configured firewalls and so on, but faxt is that they can succesfully
connect to many different ftp-servers except ours, so something must
be wrong at our side.

Do you need more information, please ask and I will give it to you.

Anyone with a suggestion would be great.

Sincerely
Martin Rådbo
Teknologia

Martin wrote:
> Some of our users have problem with the data connection using our ftp
> services. They can login fine to the ftp servers but get "Getting file
> list - timout" and similar errors when starting the data connections.
>
> Our environment is:
> FIREWALL: Linux box with Debian Woody and LDirectorD for the port
> redirection to our servers on the inside. Port 20 and 21 are fully
> open as far as we can see.
> FTP SERVERS: One Windows 2000 server and another with Linux (same
> problem connecting to both so probably the problem has to do with the
> Firewall)
>
> It does work fine from many clients out there but too many clients do
> have problems. It would be easy to blame the client computer for bad
> configured firewalls and so on, but faxt is that they can succesfully
> connect to many different ftp-servers except ours, so something must
> be wrong at our side.
>
> Do you need more information, please ask and I will give it to you.
>
> Anyone with a suggestion would be great.
>
> Sincerely
> Martin Rådbo
> Teknologia

This is a common problem with clients using a NAT connection,
and the NAT unaware of the association of the two FTP ports. The
standard FTP is trying to open the data connection to the client,
and the NAT box does not understand to send the request to
the correct host behind the router.

There are two ways to attack the problem:

- get better NAT boxes,
- use passive FTP.

Passive FTP opens the data connection from the client end,
and it passes even a crippled NAT easily. However, the
FTP server and client must support passive mode.

HTH

Tauno Voipio
tauno voipio (at) iki fi

The need for the client to use passiv mode is well known. (i.e.
normally when people have problem using the ftp you tell them to try
passiv mode and everything works fine.

But our problem is more complex. Our "problem users" do use passiv ftp
and they try with different ftp programs but still can not get the
data connection to work. But they can easily connect and send files to
many other ftp servers out there, so we can not blame them for totally
missconfigured firewalls.
Normally they use some broadband like ADSL and a home user
firewall/router like Netgear or Dlink broadbandrouters with settings
of everything allowed from the inside and out.

Any other suggestions?

// Martin

Tauno Voipio <(E-Mail Removed)> wrote in message news:<XXv3d.70$(E-Mail Removed)>...
> Martin wrote:
> > Some of our users have problem with the data connection using our ftp
> > services. They can login fine to the ftp servers but get "Getting file
> > list - timout" and similar errors when starting the data connections.
> >
> > Our environment is:
> > FIREWALL: Linux box with Debian Woody and LDirectorD for the port
> > redirection to our servers on the inside. Port 20 and 21 are fully
> > open as far as we can see.
> > FTP SERVERS: One Windows 2000 server and another with Linux (same
> > problem connecting to both so probably the problem has to do with the
> > Firewall)
> >
> > It does work fine from many clients out there but too many clients do
> > have problems. It would be easy to blame the client computer for bad
> > configured firewalls and so on, but faxt is that they can succesfully
> > connect to many different ftp-servers except ours, so something must
> > be wrong at our side.
> >
> > Do you need more information, please ask and I will give it to you.
> >
> > Anyone with a suggestion would be great.
> >
> > Sincerely
> > Martin Rådbo
> > Teknologia
>
> This is a common problem with clients using a NAT connection,
> and the NAT unaware of the association of the two FTP ports. The
> standard FTP is trying to open the data connection to the client,
> and the NAT box does not understand to send the request to
> the correct host behind the router.
>
> There are two ways to attack the problem:
>
> - get better NAT boxes,
> - use passive FTP.
>
> Passive FTP opens the data connection from the client end,
> and it passes even a crippled NAT easily. However, the
> FTP server and client must support passive mode.
>
> HTH
>
> Tauno Voipio
> tauno voipio (at) iki fi

Martin wrote:
>
>>Martin wrote:
>>
>>>Some of our users have problem with the data connection using our ftp
>>>services. They can login fine to the ftp servers but get "Getting file
>>>list - timout" and similar errors when starting the data connections.
>>>
>>>Our environment is:
>>>FIREWALL: Linux box with Debian Woody and LDirectorD for the port
>>>redirection to our servers on the inside. Port 20 and 21 are fully
>>>open as far as we can see.
>>>FTP SERVERS: One Windows 2000 server and another with Linux (same
>>>problem connecting to both so probably the problem has to do with the
>>>Firewall)
>>>
>>>It does work fine from many clients out there but too many clients do
>>>have problems. It would be easy to blame the client computer for bad
>>>configured firewalls and so on, but faxt is that they can succesfully
>>>connect to many different ftp-servers except ours, so something must
>>>be wrong at our side.
>>>
>>>Do you need more information, please ask and I will give it to you.
>>>
>>>Anyone with a suggestion would be great.
>>>
>>>Sincerely
>>>Martin Rådbo
>>>Teknologia
>>
> Tauno Voipio <(E-Mail Removed)> wrote in message news:<XXv3d.70$(E-Mail Removed)>...
>
>>This is a common problem with clients using a NAT connection,
>>and the NAT unaware of the association of the two FTP ports. The
>>standard FTP is trying to open the data connection to the client,
>>and the NAT box does not understand to send the request to
>>the correct host behind the router.
>>
>>There are two ways to attack the problem:
>>
>> - get better NAT boxes,
>> - use passive FTP.
>>
>>Passive FTP opens the data connection from the client end,
>>and it passes even a crippled NAT easily. However, the
>>FTP server and client must support passive mode.
>>

> The need for the client to use passive mode is well known. (i.e.
> normally when people have problem using the ftp you tell them to try
> passiv mode and everything works fine.
>
> But our problem is more complex. Our "problem users" do use passiv ftp
> and they try with different ftp programs but still can not get the
> data connection to work. But they can easily connect and send files to
> many other ftp servers out there, so we can not blame them for totally
> missconfigured firewalls.
> Normally they use some broadband like ADSL and a home user
> firewall/router like Netgear or Dlink broadbandrouters with settings
> of everything allowed from the inside and out.
>
> Any other suggestions?
>

Could the clients have boxes that do not understand ECN (Explicit
Congestion Notification), but the server is using it?

Tauno Voipio
tauno voipio (at) iki fi

The server is not using ECN so I don't think that is the problem.

Anyone else having a suggestion?

// Martin