Page 1 of 1

Server sent passive reply with unroutable address....

Posted: 2019-01-04 20:41
by nlk10010
We are trying to log in to an FTP server to download files. We have set things up with the FileZilla client to use Explicit FTP over TLS if available. When we try to log in we get the following (excerpt):

TLS connection established.
Status: Logged in
Status: Retrieving directory listing...
Status: Server sent passive reply with unroutable address. Using server address instead.
Command: MLSD
Response: 150 Opening BINARY mode data connection for MLSD.
Error: The data connection could not be established: ECONNREFUSED - Connection refused by server

If we change the server setting to only use plain FTP (insecure) then we can connect. The people hosting the server say there's nothing they can do, there's nothing wrong with their FTP server. Is there anything anyone can infer about this situation that points to something concrete I can ask them about or is it just that their server is set up this way? We also would like to access this server programmatically, in code, but the routines offered by our language will not use plain FTP (only over TLS), so that's a no-go until we can get this cleared up.

Any information or pointers to links or helpful documents would be appreciated.

Re: Server sent passive reply with unroutable address....

Posted: 2019-01-05 05:05
by boco
Warning: Potential lazy and/or incompetent server admins detected! :hammer:

Their server is configured incorrectly. It returns a non-routable IP address, probably a LAN IP. For plain FTP, this f*ckup is "corrected" by their malicious firewall or router (by exchanging IPs on the fly). There's a chapter about it in our Network Configuration Guide.

Of course, this will not work for FTP over TLS, as encrypted traffic simply cannot be modified on the fly. That's the whole point of end-to-end encryption.

Until they correct their configuration (data ports open, server returns the public IP), connection using FTPS would be possible in Active Mode only (needs configuration on your side).

Re: Server sent passive reply with unroutable address....

Posted: 2019-01-05 12:41
by nlk10010
Thanks for taking the time to post and help me out.

I was afraid of that; unfortunately I can't get into a fight with the server admins about this because the company that owns the server is a very important customer of the client for whom I wrote the app. They will likely try to convince MY client that I don't know what I'm talking about and I don't have time for that. I probably will end up either rewriting the relevant module in a language that supports plain FTP or switch to a hybrid setup in which an FTP client like FileZilla is used to do the download itself and the app redirects to the local folder.

Re: Server sent passive reply with unroutable address....

Posted: 2019-01-06 07:15
by boco
Just rewrite it to use Active (PORT/EPRT) mode and have the client configure their network accordingly. You can keep FTP over TLS in this case.

Avoid plain FTP whenever possible. Everything, including passwords, is transferred in plaintext and thus fully readable by anything/anyone sitting in between (Man In The Middle). Additionally, plain FTP is not tamper-resistant, everyone can modify it at will! Imagine transferring an HTML document and it arrives at the target server with malware injected, ready to strike!

Re: Server sent passive reply with unroutable address....

Posted: 2019-01-06 13:17
by nlk10010
Well, the code can't be rewritten as it's in a "high level" language with the FTP routines I've been using as supplied by the language vendor. There aren't any options to change things like ports, at least in the routines used in this module. As I say, it's worked fine up to now. I am loathe to admit (although I guess it's obvious) that this sort of stuff is not something I know too much about. I will read the relevant chapter in the "Network Configuration Guide" to see if I can figure out what Active (PORT/EPRT) mode is, but if it's going to involve the client doing something on their server then I fear I'm out of luck. They don't want to know anything about it.

Just one more thing: I discovered while playing around interactively that the client's server certificate expired around the same time all the problems started happening (this honestly could just be coincidence, of course). Also, the low level routines that stopped working initially return "invalid certificate" errors. I have asked the client if they can at least check and renew the certificate. We'll see.

Thanks again for your advice, at least this way maybe I'll learn something.