Bug: FTP with NAT can't list far directory in v4.0.3(345)

I just upgraded to WinSCP 4.0.3 build 345 and decided to try out the new FTP client functionality. I connected to an FTP server and got the following "Error" dialog:
Above text box: "Error listing directory '/'." Inside text box:
"Could not retrieve directory listing
I won't open a connection to 10.0.1.105 (only to 66.93.4.83)".

As I get this error, my laptop with WinSCP has an IP address of 10.0.1.105, and I reach the Internet through a firewall whose external address is 66.93.4.83.

If I click "OK" in the dialog, the transfer window opens without any problem other than that the remote panel only shows a "/" panel. I can transfer files to the remote side (put) without any problem, including into remote directories.

I'm pretty certain this isn't an FTP server problem because I can use the FileZilla 3.0 beta client and it doesn't have any problem.

Somewhere in the FTP remote directory listing process, WinSCP seems to be telling the FTP server to use the local IP address, assuming it's globally reachable when in my case it isn't. I would expect that you could duplicate this problem in any environment with Network Address Translation.

Can you try that with the latest Filezilla 2.x?

I finally had a chance to try FTP with the FileZilla 2.2.32 client and it also worked fine in the same environment.

I can collect packet captures or log messages. What would help?

Yes please do.

i also has the same prblem

Could not retrieve directory listing
I won't open a connection to 10.******** (only to 203.********)

martin wrote:

Yes please do.

bhavesh wrote:

i also has the same prblem

Could not retrieve directory listing
I won't open a connection to 10.******** (only to 203.********)

Please post a full log file showing the problem.

I have the same problem, but it only occurs for me when I enable TLS when connecting.

Here is my log file: <invalid link removed>

Danio wrote:

I have the same problem, but it only occurs for me when I enable TLS when connecting.

Here is my log file: <invalid link removed>

Thanks for the log.
Important line is:
500 I won't open a connection to 192.168.0.2 (only to 83.101.xxx.xxx)
Do you know what is 83.101.xxx.xxx? And why does the server retrict the IP range?

I have the same problem too. Is this still not fixed? My word. WinSCP is clearly providing the LAN IP instead of the WAN IP. WinSCP should not be leaking the LAN IP to FTP server under any circumstances. The second IP given in the error is the correct WAN IP that should have been used.

A hack fix would be to take the second IP of the error and provide that instead.
Another, better fix would be to allow users to specify their WAN IP or read it from the FTP server if it's provided.

Oh just found the passive mode option which solves the problem.

Thanks for the great free software.

martin wrote:

Danio wrote:

[...]

Thanks for the log.
Important line is:
500 I won't open a connection to 192.168.0.2 (only to 83.101.xxx.xxx)
Do you know what is 83.101.xxx.xxx? And why does the server retrict the IP range?

192.168.0.2 is my local IP, and 83.101.xxx.xxx is my public WAN IP, to which my local IP gets translated by NAT.

A hack fix would be to take the second IP of the error and provide that instead.
Another, better fix would be to allow users to specify their WAN IP or read it from the FTP server if it's provided.

Or an external service similar to www.whatismyip.org.


Just like the topic starter I have no problems changing directories manually or transferring files to the FTP server.
Finally, like Guest said, enabling passive mode does seem to solve the problem.

This issue has been added to tracker.

Anonymous wrote:

Oh just found the passive mode option which solves the problem.

Thanks for the great free software.

Yep, I had the same problem and that solved it for me as well.

So maybe not an issue after all? Maybe remove from tracker and instead edit the Wiki / common error messages?

kbrande1 wrote:

Anonymous wrote:

Oh just found the passive mode option which solves the problem.

Thanks for the great free software.

Yep, I had the same problem and that solved it for me as well.

So maybe not an issue after all? Maybe remove from tracker and instead edit the Wiki / common error messages?

I found that I also had to have the "Force IP address for passive mode connections" enabled (under Environment -> FTP).

I have the same issue too. Perhaps in the days of Firewalls and NATs, Passive should be the default mode?

Oh and for those clients who have punched holes in the Firewall the checkboxes and fields like in FileZilla server would be good:
https://wiki.filezilla-project.org/wiki/images/2/24/Serversettings_passive.png

For the third option https://whatismyip.org/ would be a good substitute option.

I think all the FileZilla features for things like these are useful including the final checkbox "Don't use external IP for local connections" which makes the settings get overridden if the user connects to a 192.x or 10.x FTP server.

Setting Passive to be the default mode would definitely save a headache that most people need not have!

Oh and for those users saying they only encounter this problem in some of the encrypted modes, your firewall/nat is re-writing your address when it passes over the wire and creating a temporary port mapping.

The reason this does not work for the encrypted channels are because your firewall/router now cannot see it! Check your server logs if you do not believe me... though you think you send 192.168.x.x by the time it passes through your router the server sees it differently!

matthew1471 wrote:

Setting Passive to be the default mode would definitely save a headache that most people need not have!

This is being tracked already.

[quote="oblique"][quote="kbrande1"]

Anonymous wrote:

Oh just found the passive mode option which solves the problem.


I found that I also had to have the "Force IP address for passive mode connections" enabled (under Environment -> FTP).

God bless you!