Opened 9 years ago

Last modified 5 years ago

#5105 reopened Bug report

"Use the server's external IP address instead" option doesn't work

Reported by: none Owned by:
Priority: high Component: FileZilla Client
Keywords: Cc: ginermail@…
Component version: Operating system type: Windows
Operating system version: Windows XP SP2

Description

The "Use the server's external IP address instead" option doesn't work as expected.
Even if the option is set, Filezilla client uses the address returned in the PASV command instead of the server's external IP address.

Note for the developper : The bug is located at line 3837 in source file ftpcontrolsocket.cpp (Filezilla client 3.3.1)
Replace the test
else if (m_pEngine->GetOptions()->GetOptionVal(OPTION_PASVREPLYFALLBACKMODE) == 2)

with

else if (m_pEngine->GetOptions()->GetOptionVal(OPTION_PASVREPLYFALLBACKMODE) != 1)

It looks like the option can't have the value "2" so the test returns false everytime.

Change History (7)

comment:1 Changed 9 years ago by Tim Kosse

Resolution: rejected
Status: newclosed

This is by design. For debugging purposes, the value can be set to 2 manually. This is not intended to be used by users. Instead, the user is supposed to pick up the phone, call the server administrator and tell him to fix the broken server configuration so that it works without any ugly workarounds.

comment:2 in reply to:  1 ; Changed 9 years ago by none

Priority: blockerhigh
Resolution: rejected
Status: closedreopened

Replying to codesquid:
I'm also the administrator of the FTP server and it is correctly configured.
The problem is that there is some NAT on the path between the client and the server.
And depending of the subnet location of the client, the IP address to use to reach the server is not the same. For instance client 1 uses an server IP address aaa.bbb.ccc.dddd and another client 2 uses the server IP address eee.fff.ggg.hhh.
These addresses will be NAT'ed to the real server IP address www.xxx.yyy.zzz (which is the address returned in the PASV command).
The NAT for client 1 is done by a FW and the NAT for client 2 is done by another FW.
That's why the IP addresses to use are not the same. The choice of the IP addresses aaa.bbb.ccc.dddd or eee.fff.ggg.hhh is done by the local administrator of each FW.

I don't understand why you say that this option is for debug purpose.
If the IP address returned by the FTP server is in a reserved range (127.0.0.1, 10.x.y.z, 192.168.a.b,...), then the option is working as expected.
But if the IP address returned is a "routable" one (which is my case) then it doesn't work.
Where is the logic ?

I have tried to modify the FTP server configuration in order to returned an IP address 127.0.0.1. And it works ! But ... it cause trouble for some programs who makes FTP transfers (without using filezilla) from non nat'ed locations because they try to connect to the address return in the PASV command.
So I can't solve the problem easily and the "Use the server's external IP address instead" option is really the good solution (And it is not only for debug).

Well, if you don't want to make the modification, could you explain me how to set the value manually ? (I tried to change it directly in the configuration file, but it is overwritten as soon as filezilla is started).
I have already tried to recompiled the code with the modification described in my mail and it is working but I have some graphical problems (side effects probably due to my dev environment). So it's not the solution.

comment:3 in reply to:  2 Changed 9 years ago by none

Replying to tmp1:
One comment: I've tested again the modification of the value manually in the configuration file and finally it works. I think that in the previous test I had opened the configuration panel and closed it by clicking on the ok button which had lead to modify the value back to 1.

But I still think that the "Use the server's external IP address instead" option should be taken into account if checked whatever the IP address returned by the server in the PASV command.

comment:4 in reply to:  2 Changed 9 years ago by none

Replying to tmp1:
In order to avoid misunderstanding about the kind of NAT.
It is not masquerading (modification of the TCP port; NAPT port translation) but instead a destination address modification (Static Network Address Translation).

comment:5 Changed 9 years ago by Tim Kosse

Resolution: rejected
Status: reopenedclosed

NAT is broken by design, but that isn't the point.

Your server is configured incorrectly if it reports the wrong address, please properly configure the server.

comment:6 in reply to:  5 Changed 9 years ago by none

Replying to codesquid:
I agree that FTP protocol has not been designed with NAT in mind and that's why FTP client should implement options to allow FTP users to circumvent the problem.

As already explained my server is correctly configured.
It just can't return in the PASV command an address it doesn't know.
In case of NAT of the destination address, the server doesn't know the IP address used by the client to reach it.

If you don't understand the usefulness of my request (or don't want to implement it), well, I will try to find another solution to solve the problem and won't reopen the ticket.

But that's really a pity.

comment:8 Changed 6 years ago by Stanislav German-Evtushenko

Cc: ginermail@… added
Resolution: rejected
Status: closedreopened

Hello,

"Use the server's external IP address instead" still doesn't work as expected or I somebody could tell me how it is supposed to work?

Test environment:

  • Misconfigured FTP server behind NAT
  • Filezilla client connects through squid proxy server (HTTP/1.1 using CONNECT method) to that FTP server

Result:

  • Filezilla first connects to the external IP address of the FTP server and then tries to connect to passive ports using it's private address and obviously it can't do this

Expected result:
"Use the server's external IP address instead" option should replace local IP address by external one when using passive mode. Or this option should be removed from Filezilla completely in order not to confuse.

Note: See TracTickets for help on using tickets.