Make Linux command line ftp client ignore local IP address in passive mode

3

1

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.

Martin Ørding-Thomsen

Posted 2017-02-08T12:06:27.170

Reputation: 133

1This should be solved at the NAT level (via the FTP module of ip_conntrack) – Eugen Rieck – 2017-02-08T12:26:08.063

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 – 2017-02-08T14:25:20.760

Answers

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).

Martin Prikryl

Posted 2017-02-08T12:06:27.170

Reputation: 13 764

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 – 2017-02-10T12:30:49.443

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.

Curtis Reynolds

Posted 2017-02-08T12:06:27.170

Reputation: 1

1"CLIENT needs to ignore the PASV IP" - Why? Where in FTP RFC did you see such claim? – Martin Prikryl – 2018-03-23T20:13:09.493

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 – 2018-03-25T04:28:35.813

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 – 2018-03-25T04:47:39.700

I'm a little surprised an author of FTP client software needs that simple fact explained. – Curtis Reynolds – 2018-03-25T22:33:29.087

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 – 2018-03-26T06:02:35.960

For example in your case, you can configure two FTP servers with the same backend/storage. One for internal use and one for external use. - Or some FTP servers (like ProFTPD) allow network interface-specific configuration. So you can configure a different IP address for different interface. - Or for internal use, make sure that everyone uses an FTP client with EPSV support, with which there's no issue with IP. And configure the FTP server with an external IP address (for external clients, which you do not control). – Martin Prikryl – 2018-03-26T06:10:51.350