Passive FTP connections should work out of the box in Plesk. If no other firewall or NAT is interfering with it.
I’ve recently noticed that when I install Plesk on Amazon EC2 every passive FTP connection fails with an error such as “Server sent passive reply with unroutable address. Passive mode failed.”
The reason for this mishap is twofold:
EC2 instances are behind a NAT, and therefore have an internal (unroutable) IP, and an external (public) IP. When a passive connection request comes in, ProFTP – Plesk’s default FTP Server – tells the connecting client its internal private IP address, and in turn quite rightly fails to connect to it.
On top of that, we need to make sure to open a range of ports we want to use for passive FTP connections and tell ProFTP only to use those.
Let’s do all this this step by step!
Open Ports in the AWS Security Group
The IANA-registered ephemeral port range is 49152-65534, so we should be able to use any of those. To allow a good number of simultaneous connections let’s settle for 100. How about 50001 – 50100?
Let’s add those as allowable incoming connections to our security group. Login to the AWS admin interface and select the EC2 instance in question (the blue box in front of it). Find the security group at the bottom right and click on its link which will take you straight to that group.
While you’re here, make a note of the public or elastic IP address and remember it for later.
This will take you to a screen that allows you to edit your group. Hit Edit and add your choice of ports to the end of this list. Make sure to select “Anywhere” in the last column:
Press save and those ports are open immediately.
We need to tell ProFTP about those ports and tell it our public IP address.
Login as root and edit the ProFTP configuration file at /etc/proftpd.conf. Put the following two lines at the very top of the file. You can even preface it with a comment so you remember what we did here:
# adding passive ports and public IP address
PassivePorts 50001 50100
The first line defines our passive port range, and the second line tells ProFTP which IP to give out to potential clients. Needless to say, replace it with your own.
All that remains is to restart ProFTP – which in Plesk is part of xinetd:
service xinetd restart
Stopping xinetd: [ OK ]
Starting xinetd: [ OK ]
Check if it works
Tim Kosse from the FileZilla foundation has a fantastic website that lets you test an FTP connection and displays a detailed status log. He also tells you many gory details about FTP in general and how it works – it’s a great read. Have a look here: http://ftptest.net
Hack in your details to connect to your server and see what happens. There should be no more error when the server calls PASV.
If your connection still displays an error message about that unroutable private IP, make sure your internal firewall isn’t blocking those ports. If it does, open them with the following and test again:
iptables –I INPUT –p tcp --dport 50001:50100 –j ACCEPT
You may receive a “Line feed received without preceding carriage return” but that’s nothing to worry about. Passive FTP is working, that’s all that counts.
Thanks Tim, and thanks Ivan for pointing me in the right direction 😉