Networks

Ask something
Discussion Locked

Cannot FTP to a specific server

0 helpful
4 replies

by tomtowle

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

I am having a problem using standard FTP clients to connect to a specific FTP address. I have two Class C networks behind a packet-filtering firewall connected via T1 to the Internet. From one network I have no problems, however, from another I am unable to connect using command line or application FTP on several different workstations.

If I try using a Unix box, it will sit there waiting for a connection and eventually time out.

ftp>open host.domain.net
Connected to 123.34.567.89....^C
ftp>

If I use another ftp server site
ftp>open other.domain.net
Connected to 234.56.233.23
220 proserver1016 Microsoft FTP Service (Version 4.0)

Any ideas?

4 replies

by mckaytech

From your limited description, I would say the firewall is a prime suspect. If I understand the description, there is one FTP site you can't reach from one network but from that network you can reach other FTP sites. And from the other network youcan reach this one FTP site as well as all others.

It sounds like a port blockage issue rather than a routing issue, but you might try pinging the FTP server to confirm that.

Otherwise, if you have access to the firewall configuration, you're looking for a rule that denies FTP (port 21) to the address (or address range) that you're trying to reach. Each rule specifies a source, a destination and a port so there could easily be a rule that blocks Port 21 packets from one subnet to particular destination address.

paul

by tomtowle

I should have mentioned that I had already tried lowering the firewall with no results. Additionally, the Network Administrator reports seeing many ICMP packets coming in. PINGing generates ICMP and will be intercepted by the firewall at his end.
I am starting to believe that his proxying firewall has registered my domain IP as a "deny" range because programmers here may have PINGed it massively in trying to solve their problem.

Since we ONLY have problems FTPing to their FTP server fromOUR domain and NOT a borrowed domain we use over the SAME T1, and can FTP to other sites with no problems, I do not beleve that the port deny is a problem. I AM curious as to why ICMP packets are showing up when we try to connect with a standard Unix FTP client application.

by some guy in seattle

You do not say what kind of firewall you are running (i.e. "packet filtering = PIX" to me, as opposed to something else).

There are some issues with DNS concerning FTP transfers. A lot of sites set up their FTP servers to do a reverse lookup on a requesting client, and if the requesting IP cannot be resolved, it is denied. Often times, this is because sites that have to pay attention to export laws regarding encryption (among others) need to verify if high-encryption is allowed to be downloaded to a client (must be in North America). Some sites enable reverse lookup just for their own info. In either case, make sure that your IP address(es) are registered in your/your ISP's DNS server's in-addr entries. This will allow the FTP siteto do the reverse lookup and then authorize the login.

A good basic test is to temporarily reassign your UNIX client to the "known good" network and verify that it can FTP fine. If so, I would suspect DNS on the second network.

A second test is to check the rules on the firewall to be sure they are consistent with what is known to be good for the first network (basic, I know, but I've fallen for this a couple of times! :) ).

Hope that helps,

by shanghai sam

Our firewall is a packet-filtering firewall. Our reverse-lookup is OK and so is theirs. The problem is seeming more and more like it is in their proxy-filtering firewall. They have set up a rule just for our FTP client app and state that they are no longer getting error alerts. It may well have been

I am hesitant to try the "reassignment" method as that client app lives on our ERP. I have "dropped" the firewall in order to test the effect our filter rules have and received the same results.

I do however, much appreciate the level of thought and intent given to your answer.

This discussion is closed to new replies.