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

Advertisement

esobocinski
Joined:
Posts:
2

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.

Reply with quote

Advertisement

esobocinski

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?

Reply with quote

bhavesh
Guest

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.

Reply with quote

Advertisement

martin
Site Admin
martin avatar
Joined:
Posts:
40,476
Location:
Prague, Czechia

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.

To generate log file, enable logging, log in to your server and do the operation and only the operation that causes the error. For posting extensive logs you may use pastebin or similar application. Note that passwords and passphrases not stored in the log. You may want to remove other data you consider sensitive though, such as host names, IP addresses, account names or file names (unless they are relevant to the problem). If you do not want to post the log publicly, you may email it to me. You will find my address (if you log in) in my forum profile. Please include link back to this topic in your email. Also note in this topic that you have emailed the log.

Reply with quote

Danio
Donor
Joined:
Posts:
2

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>

Reply with quote

martin
Site Admin
martin avatar
Joined:
Posts:
40,476
Location:
Prague, Czechia

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?

Reply with quote

Guest

aaaaaaaa

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.

Reply with quote

Advertisement

Danio
Donor
Joined:
Posts:
2

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.

Reply with quote

kbrande1
Guest

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?

Reply with quote

Advertisement

oblique
Guest

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).

Reply with quote

matthew1471
Guest

Same issue

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

Reply with quote

matthew1471
Guest

Re: Same issue

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!

Reply with quote

martin
Site Admin
martin avatar

Re: Same issue

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.

Reply with quote

Advertisement

Tinchote
Guest

[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!

Reply with quote

Advertisement

You can post new topics in this forum