ftp problem: 421 service no available

[Allen Lai_1]

Hi all,
has anyone experience this problem?

After i connect ftp server successfully and would like to put some files on a ftp server (HP-UX 11i), the error message "421 Service not available, remote server has closed connection" was shown in my log. (my ftp client is HP-UX 10.20) Some questions on this problem:

1. The error message "421 Service not available" is a response of ftp Server? or it is generated by client.
2. is there any meaning with 421? does it is a return code of ftp?
3. what situation can cause this problem? (misconfiguration of ftp server and firewall, or unstable network...or ftp client)

thanks for all your kindly help!!

[Suresh Patoria]

Hi,

first check in the system allow to do ftp in the locally

See if it is allowing then also check /var/adm/inetd.sec there is some etnry for ftp.

Thanx

[Sergejs Svitnevs]

An FTP server probably is configured correctly, but the problem is with authorizing users at login or you are behind a firewall that isn't allowing the incoming reverse connection from the ftp server to your client.

According RFC Nr. 2577
"To minimize the risk of brute force password guessing through the FTP server, it is suggested that servers limit the number of attempts that can be made at sending a correct password. After a small number of attempts (3-5), the server should close the control connection with the client. Before closing the control connection the server must send a return code of 421 ("Service not available, closing control connection." to the client."

Regards
Sergejs

[Allen Lai_1]

Dear all,

Sorry i lost one thing...

The problem happen "SOMETIMES". I schedule the ftp as a automatic job every day, and the job contains 6 times data generation and 6 times ftp specifically to transfer the data to another server.

But sometimes...there is always one ftp failed and display the error message.

i think there should be 3 division related to this problem (ftp client, network/firewall, ftp server), but have no idea on investigation.

[Ron Kinner]

When working FTP through a firewall you should use passive mode to make your life easier. If not, that could be your problem.

You may also be dropping packets somewhere along the way. If you have a Cisco router, get the admin to do an extended ping of your IP address and let it sweep a range of sizes. This causes the ping to start small and send a string of ever increasing packet sizes. The results look like a bunch of !'s. If you get a . that means it dropped a packet. If you qet Q's you need to turn off source quench in ndd. We had problems with FTP and it turned out to be a bad NIC which was known to be sensitive to EMI. This test revealed it.

How long does your file transfer take? Some firewalls think it is their business to limit connection time.


If your FTPD does lookups to verify the user name so it can check the priv's then you could be having DNS server timeouts which might cause it to drop your conection.

You may need to run TCPDUMP to see what is happening.

Ron

[Allen Lai_1]

Hi all,

The cause was figured out....

After a long testing and investigation, we find the problem was caused by our firewall (CheckPoint). It's a security consideration of CheckPoint. The problem description was as the below:

Problem Description
====================
File Transfer Protocol (FTP) data connections are dropped by the FireWall
Error received in the info field of the log viewer
Error: 'reason: tried to open tcp service port, port: '
FTP Data connections reject on Rule 0

Cause of this problem
======================
This error occurs when a FTP PORT command issued tries to open a TCP port that is listed as a Service inside the Firewall-1 services. It is a security implementation to keep anyone from injecting false PORT commands and opening up any high ports through an FTP session. For example, malicious JAVA applets can take advantage of this situation, causing the FTP client to send a PORT command with ports like TELNET, X, REXEC, etc. This will lead the FireWall to open this port, which could be followed by hacking a certain server on the machine.

According to the explaination of CheckPoint, Once the TCP port (even higher than 1024) used by ftp client for ftp data connection is defined as a well-known port for specific network service, the ftp session will be reject by firewall.

We are trying to make server unable to use those ports (although I don't think it is reasonable to make this limitation on my system), and trying to find out any workaround or patch.

Anyway...really thanks for all your great help and clue. ^^

Thanks!!
Allen

[Michael Schulte zur Sur]

Hi Allen,

you didnt write, whether you checked on using
passive mode like Ron suggested. The passive mode allows the server to choose the port and thereby opens the connection and not the client.

greetings,

Michael

[Ron Kinner]

Trying to get the FTP server to use a port lower than 1024 to dial back on an active mode FTP connection is probably not going to work. You have to use Passive (PASV) mode. Verify that the FTP Server supports passive. Log on from the client and issue the command which will be either "passive" or perhaps "pasv"

On some servers you can set the port range that it will use with the command
passive ports
This command is not standardized all that well so check your server's man ftpd for the exact syntax.

Ron

[Allen Lai_1]

Hi all,

I was using active mode.

I am using passive mode now, and it seems we can avoid the problem.

There's one thing that i cannot understand. In the passive mode, the TCP port used by ftp server for data connection should be greater than 1024 and random. Theoretically, i have to add a new policy ( "source port any" "destination port any"
"action permit") in firewall to permit ftp passive access. But i don't add the policy, why the passive ftp still can work?

Thanks!!
Allen

[Michael Schulte zur Sur · Accepted solution]

Hi Allen,

have a look at this site:
http://slacksite.com/other/ftp.html
it show nicely, what the difference is between active and passive ftp is concerning the firewall.

I am still scratching my head,

Michael