Opened 2 years ago
Last modified 2 years ago
#12723 closed Bug report
Un-routable server address bypasses the setting in passive mode to use control socket address — at Initial Version
Reported by: | QIU Quan | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | FileZilla Client |
Keywords: | passive un-routable | Cc: | QIU Quan |
Component version: | 3.60.0 | Operating system type: | Windows |
Operating system version: | Windows 10 20H2 (10.0.19042.1706) |
Description
The client is connecting to a server behind an NAT router, whose IP address facing us is also a private address, as illustrated below.
+------------+ +----------------|------+ +--------------+ | my client | | NAT router | | their server | | 172.21.x.x +---+ 192.168.200.32 | 10.x +---+ 10.10.x.x | +------------+ +----------------|------+ +--------------+
I left the setting for "Connection / FTP / Passive mode" by default, to "Use the server's external IP address instead". However, it did not work for me.
The attached log file 20220601-1751.log
shows at lines 82 and 161 that the server replied with its private address, and a netstat
command on the client at the moment showed it was actually trying to connect to exactly the server's private address.
I noticed a trace message in the log file, i.e.
Destination IP of data connection does not match peer IP of control connection. Not binding source address of data connection.
Having searched this message in the source code, I landed a function CTransferSocket
:: SetupPassiveTransfer
, and found that its host
argument seems to be assigned in the function CFtpRawTransferOpData
:: ParsePasvResponse
.
Inside ParsePasvResponse
, the condition to assign the peerIP
from the control socket to the host_
of the passive data connection is an un-routable data peer address as well as a routable control peer address. Unfortunately, with all un-routable, internal addresses for both data and control, my scenario effectively bypasses this mechanism.
At the end of the ParsePasvResponse
function, I noticed that I can instruct the client to always use server address by setting the option OPTION_PASVREPLYFALLBACKMODE
to 2
, which is set by an option named Pasv reply fallback mode
, stored in %appdata%\FileZilla\filezilla.xml
. I wonder the intention to omit this option in the settings UI, but it indeed provides a workaround for my situation in the current version.