4

I'm trying to connect to an FTP server that is behind a NAT. The local IP of the server is 172.23.11.41 and the public IP is 194.239.61.58, and I'm connecting to the public IP.

When entering passive mode the server returns its local IP address which is useless. Example:

227 Entering passive mode (172,23,11,41,234,113).

The Linux command-line ftp client cannot establish a data channel when this happens.

I need to get the ftp client to ignore the IP address returned by passive mode (PASV) or to use extended passive mode instead (EPSV), which only returns the port number. Example:

229 Entering extended passive mode (|||64607|).

Is there any way to do this?

Edit: I'm being told that we use ftp.x86_64, installed by calling sudo yum install ftp.

Improve this question
2
  • 1
    This should be solved at the NAT level (via the FTP module of ip_conntrack)
    – Eugen Rieck
    Commented Feb 8, 2017 at 12:26
  • You might consider using active mode in your FTP client (and your question really should say which one you're using; there are several FTP clients that are part of Linux distributions).
    – Toby Speight
    Commented Feb 8, 2017 at 14:25

2 Answers 2

Reset to default
4

Get the server fixed. It should be configured to report its external IP address. Or the NAT should be configured to translate the IP in the PASV response.

The common *nix ftp command-line client cannot be configured to use the EPSV or to use the control connection IP instead of the IP returned in the PASV response.

Or use another FTP client, like tnftp (use the epsv4 command) or curl (defaults to the EPSV).

Improve this answer
1
  • Thank you. I think some of the users of the server have go through natting and some don't, so we cannot get the server fixed since it reports the correct address for some users. We could set up additional natting for our outgoing calls as you suggest, but it isn't pretty. We'll just use another client. Thank you.
    – Martin Ørding-Thomsen
    Commented Feb 10, 2017 at 12:30
0

Martin Prikryl:

"Get the server fixed. It should be configured to report its external IP address. Or the NAT should be configured to translate the IP in the PASV response."

I am an FTP administrator at a major institution, where we use 4 node HA clustered FTP environments. 2 active, and 2 standby, all load balanced and NAT'd. The issue is not necessarily a "server fix". Our servers all respond with the local IP's for PASV connections. However, if the LB's and NAT's are correctly configured, the CLIENT needs to ignore the PASV IP and use it's control connection IP when connecting through the LB. The ACTUAL problem is a linux FTP/S client failure. Our configuration is a normal, standard, configuration, which works beautifully with ALL OTHER CLIENTS who connect to our FTP systems. We ONLY see this problem when using FTP/S on linux boxes or our mainframe. On linux and IBM z/OS, the FTP/S client won't allow the PASV connection if the PASV is different from the control channel IP.

Just wanted to explain that.

To the original poster: That being said, you might try: ftp:ignore-pasv-address and see if that will allow you to make the data channel connection.

Improve this answer
6
  • 1
    "CLIENT needs to ignore the PASV IP" - Why? Where in FTP RFC did you see such claim?
    – Martin Prikryl
    Commented Mar 23, 2018 at 20:13
  • 1
    Because it's a common configuring when FTP servers are sitting behind both public facing and internal facing firewalls, and have to service both internal and external clients. This is, after all, the reason that virtually (VIRTUALLY) every FTP client has the ability to ignore the PASV IP response. As for NAT translating the IP address in the PASV response, on encrypted connections NAT has no knowledge of the packet contents that contain the PASV response.
    – Curtis Reynolds
    Commented Mar 25, 2018 at 4:28
  • Further, since the RFC for FTP ambiguously defines the PASV response... ie it does not define specifically what host and port are to be returned, only what host and listening port the server will use... this is not a matter of the FTP RFC. This is a matter of network configuration and client accessibility.
    – Curtis Reynolds
    Commented Mar 25, 2018 at 4:47
  • I'm a little surprised an author of FTP client software needs that simple fact explained.
    – Curtis Reynolds
    Commented Mar 25, 2018 at 22:33
  • It's not that I need it to be explained. I understand you. I just do not agree. Imo, it's administrator task to make his/hers server working with every FTP client that complies with RFC. And if not possible, simply use a different technology, like SFTP. - I understand that you may need to do a pragmatic decision is some cases. But do not claim that it's something that should be followed in every case, without questioning.
    – Martin Prikryl
    Commented Mar 26, 2018 at 6:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .