Ftp – vsftpd – The data connection could not be established: EHOSTUNREACH – No route to host

The chances are good that your firewall supports FTP by watching the control connection (basically what you pasted above) and opening ports dynamically to enable the data connection to be made (where it said: "150 Opening BINARY mode data connection.").

You've encrypted the control connection. The firewall can't see inside to do that.

What you'll want to do is edit the firewall to permit a range of ports (how many depends on the number of clients you'll have) to enter (or leave, if you're permitting "active" PORT commands instead of or in addition to PASV). You will then need to configure the FTP server to only use those ports.

It is hard / annoying, but I've seen it work with at least one secure FTP server

Dealing with these types of problems can be difficult because the logs usually tell you only part of what is happening.

Your best bet at this point is to use a packet capture and analysis software (like the most excellent - and free - wireshark) to see what is really going on the wire.

Make sure you capture all the traffic between your machine and the remote system and try to see what difference you can spot between a working connection and your code. That might give you an indication where the problem lies.

Do pay special attention to the way the TLS connection is negociated because it might point out to the actual issue (there is a pretty nice and simple to understand document that can be found at IBM's). For instance:

• If the connection stops after certificates have been exchanged, it is an indication that one of the parties cannot verify the other's certificate. This is a quite common source of problem with TLS software, especially when self-signed certificate or private roots are used.
• If the connection is broken in the first stage of the handshake, it can be that the client and server cannot agreed on what protocol to use (usually because one of the party restricts itself to "safe" protocols that the other does not support).
• If the server has set the "client certificate required" flag, then it could be that you haven't setup a client certificate for authentication.
• (etc)

If you see that the TLS channel has been successfully negociated, then you'll have to gring in the big guns: grab the server's private key and decode the TLS traffic. That will only be possible, however, if the TLS connection does not use DH key exchange so first, disable that in your server or client.

Once DH has been deactivated and you have the private key, you can follow the instructions on the Wireshark's wiki page about SSL/TLS which explains the process in quite a bit of details or this blog post that is perhaps a bit easier to follow.