Home Forums .NET libraries Xceed SFTP/FTP for .NET Unable to establish an FTP connection

Viewing 1 post (of 1 total)
  • Author
    Posts
  • User (Old forums)
    Member
    Post count: 23064
    #21467 |

    There are 2 main reasons that can cause an FtpClient or an FtpConnection to fail to open a connection. 

    The most common reason is that the PassiveTransfer property is set to false.  If this is the case, it means that the server end will try to open the data channel on a given range of ports when sending directory content and files to the ftp client.  If the ftp client’s firewall is not set to receive those incoming connections from the ftp server, the connection will fail.  Add to this that if the ftp client is behind a router, the router must also have settings to forward the port to a specific IP address on the local network.  Most of the time, PassiveTransfer should always be set to true. Passive transfer are not less efficient than active transfers.

    The second most common reason is the use of FTP SSL.  You can have a good reason for encrypting the content of an FTP session but often here is what will happen: the NAT (Network Address Translation) of the router at the FTP server site won’t be able to properly translate the local IP address from 192.168.1.1 (hypothetical configuration) to the public IP address of the site because of the address being encrypted.  Your ftp client will receive a LAN (Local Area Network) IP address and it will try to connect to it. This can be avoided by setting the FtpClient/FtpConnection UseRemoteAddress property to true.  In this case, the FTP client will always use the address originally used to establish new data channels, even when the FTP server is telling the FTP client that its IP address is 192.168.x.x or similar local network addresses. Also, even when not in an SSL session, the NAT at the server site won’t do the IP translation properly and what you will receive is a LAN IP address.  Note that the UseRemoteAddress property is only supported in version 4.0 and later of our FTP for .NET component.

    Hypothetical Network Configuration:

    Client (10.0.0.1) — Firewall (174.85.15.47) ———- INTERNET ———- Firewall (219.135.43.13) — Server (192.168.1.1)

    Transmission symbols:

    Client:  >

    Server:  <

    Non-SSL /TLS connection:

    > Connect to 219.135.43.13 (public address)

    < 220 Welcome connection accepted,

    > USER user

    < 331 pass required

    > PASS pass

    < 230 User logged in

    > TYPE I

    < 200 Type set to I.

    > PASV

    < 227 Entering Passive Mode (219,135,43,13,5,185)

    > LIST

    < 150 Opening ASCII mode data connection for /bin/ls.

    > 226 Transfer complete.

    Everything is OK here since the NAT did its job and translated the 192.168.1.1 address from the server to the public 219.135.43.13 address.

    SSL /TLS connection:

    > Connect to 219.135.43.13 (public address)

    < 220 Welcome connection accepted,

    > USER user

    < 331 pass required

    > PASS pass

    < 230 User logged in

    > TYPE I

    < 200 Type set to I.

    > PASV

    < 227 Entering Passive Mode (192,168,1,1,5,185)

    > LIST

    < 150 Opening ASCII mode data connection for /bin/ls.

    > 226 Transfer complete.

    In this case, the NAT did NOT do its job, so the client tries to connect to 192.168.1.1, which will be unreachable. If you use the UseRemoteAddress parameter, the host address will always be used when establishing a data exchange connection.

    Applies to Xceed FTP for .NET. Imported from legacy forums. Posted by Xceed admin (had 3897 views)

Viewing 1 post (of 1 total)
  • You must be logged in to reply to this topic.