5

I'm using vsftpd on a Debian server behind another Debian firewall. The natting is correct and I can connect to the ftp server from the outside. However, when the client issues the PASV command, the ftp server returns its internal IP (192.168.0.19).

I do not have the pasv_address directive set inside the conf file so that "the address is taken from the incoming connected socket" (copied out of the manual). It seems to me that when an external client issues PASV, the firewall's external IP address should be returned, and when an internal client connects, the internal FTP server's IP should be returned.

When I set the pasv_address directive to the firewall's external IP, everything works externally but then it breaks internally. When I either set it to the internal IP address or comment out the pasv_address, the internal clients work but the external ones don't.

Anyone have any insight there?

Edit 1: Here is the server-side log file:

Thu Sep  7 10:36:15 2017 [pid 9093] FTP command: Client "x.x.x.x", "USER yyy"
Thu Sep  7 10:36:15 2017 [pid 9093] [yyy] FTP response: Client "x.x.x.x", "331 Please specify the password."
Thu Sep  7 10:36:15 2017 [pid 9093] [yyy] FTP command: Client "x.x.x.x", "PASS <password>"
Thu Sep  7 10:36:15 2017 [pid 9092] [yyy] OK LOGIN: Client "x.x.x.x"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "230 Login successful."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "OPTS utf8 on"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "200 Always in UTF8 mode."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "PWD"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "257 "/""
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "CWD /DownloadProduction/"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "250 Directory successfully changed."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "TYPE A"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "200 Switching to ASCII mode."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "PASV"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "227 Entering Passive Mode (192,168,0,19,192,27)."

Edit 2: I was able to get this working using ProFTPD. Here is the serverfault case for that: ProFTPd server behind firewall returns internal IP address for WAN and LAN connections

Lifz
  • 203
  • 1
  • 2
  • 8

4 Answers4

2

To get this working using vsfptd, I did a few things:

  1. Changed the conf file for the existing vsfptd service
    • Listen on port 2121
    • Respond with external IP
  2. Forward port 21 from the firewall to port 2121 on the ftp server
  3. Added a second vsftpd service (named vsftpd-internal)
    • Listen on the default port 21
    • Respond with internal IP

This makes the existing service handle external connections only and the new vsftpd-internal service handle internal connections only.

Edit to show conf options (requested in comments)

External (/etc/vsftpd.conf):

listen_port=2121
pasv_address=x.x.x.x # External IP - port forwarded from FW to this machine

Internal (/etc/vsftpd-internal.conf):

# nothing special in this one, mostly default
Lifz
  • 203
  • 1
  • 2
  • 8
  • Could you please show the configurations you used to achieve the changes you have stated? – Henry Dec 11 '18 at 22:12
1

FTP causes headake very often, because it doesn't do data transport on the already-established control connection, but requires to open an additional connection for transporting data. The first version of FTP required the server to open this connection to the client - this was at times where NAT was unknown. To make this work with NAT, PASV was invented, so the client could open this second connnection. Better, but - as you experienced - not optimal.

Three options come to my mind:

  • You use sftp instead - it doesn't suffer from this problem, because it is essentially using ssh for control and data in one and only one connection. Of course this is a different protocol, so depending on your environment this might not be an option.
  • Instead of NATing on your Debian firewall, you use some ftp proxy software like "ftp-proxy".
  • You set up two vsftp servers, one listening for internal connections on standard port, another one on, say, 2121, for external use, which gets pasv_address configured to the firewall's external IP. NAT needs to be adapted to translate port 21 into port 2121.
TomTomTom
  • 611
  • 3
  • 6
  • Thanks! I ended up doing your 3rd option using ProtFTDP like @MartinPrikryl suggested. – Lifz Sep 12 '17 at 12:29
1

If you are behind an external firewall, the incoming connection comes actually from the external firewall. So the server IP address is its internal IP address. What you describe is a "correct" behavior. The FTP server is not aware (and cannot be) of the external IP address of the firewall.

What you can do is to assign two IP addresses to the FTP server. One for an external use and one for an internal use. And configure the FTP server to return the firewall external IP address for connections on the external IP address; and internal IP address for connections on the internal IP address.

Though I'm no sure, if vsftpd does allow such configuration. ProFTPD does.

Martin Prikryl
  • 7,756
  • 2
  • 39
  • 73
  • What is strange is nothing has changed other than updating to Debian 9 and all the sudden our external client can't connect. They say it breaks when we send back the internal IP address of 192.168.0.19 but when I look in the logs, it's always sent that back to them. The update to Debian 9 seems to have broken whatever was allow it to work before! – Lifz Sep 07 '17 at 13:35
  • Do they have client-side logs from before? – Martin Prikryl Sep 07 '17 at 13:45
  • I asked them about this and unfortunately, it seems as they do not. I can't get my mind around why all of the sudden it's not working. They have assured us that they did not make any changes and to their credit, the issue only arose after we upgraded to Debian 9 and rebooted. Almost to the minute. – Lifz Sep 07 '17 at 15:18
  • By any chance, hasn't the upgrade enable TLS/SSL encryption in vsftpd? – Martin Prikryl Sep 07 '17 at 17:41
  • Anyway, this out of scope of your original question. – Martin Prikryl Sep 07 '17 at 17:42
  • Thanks for getting back to me. I don't think it turned on TLS/SSL. The only difference is we upgraded from Debian 8 to Debian 9, rebooted, and now when they issue the PASV cmd, and we respond with 192.168.0.19 (as we always have), it breaks for them. This is now happening to 2 outside clients. – Lifz Sep 07 '17 at 18:12
  • Can you show us at least server-side log file? – Martin Prikryl Sep 07 '17 at 18:18
  • Sure, I will edit the question to include the log file from the server side. – Lifz Sep 07 '17 at 19:18
  • While trying to fix this, I'm simultaneously adding ProFTPD to another server. I have set `MasqueradeAddress mydomain.com` and it's just passing back the internal IP address (obviously). I think I need to find how to do what you said and make ProFTPD respond to external vs internal somehow. – Lifz Sep 07 '17 at 19:23
  • I think you need two IP address or at least two port numbers. And then you can nest the `MasqueradeAddress` within [`VirtualHost` configuration block](http://www.proftpd.org/docs/directives/linked/config_ref_VirtualHost.html). If you use a different ports, you can use a standard port 21 for an internal use and a different port number for an external use. On the external firewall, you can map an external port 21 to the other port. – Martin Prikryl Sep 08 '17 at 05:56
  • I'm going to accept your answer because this is how it should work. It doesn't help me get by yet but your answer is still correct. It also pointed me to ProFTPD for which I will open a new question. I do not want to use 2 IP addresses and ProFTPD documentation seems to suggest you don't need to. I'm of the understanding that using IPTables to forward traffic to ProFTPD should allow it to "see" that connections as WAN vs inside traffic as LAN. At least that's my hope :) – Lifz Sep 08 '17 at 15:27
0

In my lab with two internet links it worked to download an internal server file to a Windows client outside the internal network. The test on the internal network also worked. I don't know if I did shit! After many hours It works! Could anyone evaluate !!

  • FIREWALL: => allow in 50000:50999/tcp
  • ROUTER: => PortForward: 50000:50999/tcp

vsftpd config:

pasv_enable=YES
pasv_addr_resolve=YES
#pasv_address=xxx.xxx.xxx.xxx <=my external Ip 
pasv_address=domain.com.br <= my domain
pasv_min_port=50000
pasv_max_port=50999

/etc/hosts:

127.0.0.1 domain.com.br
192.168.1.253 domain.com.br [192.168.1.253] LOCAL IP SERVER

download command:

wget --no-check-certificate -i -r ftps://user:passwd@domain.com.br:990/files/report.rar
Andrew Schulman
  • 8,811
  • 21
  • 32
  • 47
Paulo Giovanni Brazil
  • 1
  • 1