Post a reply

Before posting, please read how to report bug or request support effectively.

Bug reports without an attached log file are usually useless.

Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)


Topic review


Re: Force IP Address Functionality - Bug?

Please attach a full session log file showing the problem (using the latest version of WinSCP).

To generate the session log file, enable logging, log in to your server and do the operation and only the operation that causes the error. Submit the log with your post as an attachment. 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 can mark the attachment as private.

Force IP Address Functionality - Bug?

I was working with one of our clients to establish their FTPS connections with our system. From our testing environment things worked well but when the attempt to connect to our produciton hosts the data channel could not be established. We found this issue was with the passive reply. In the testing environment our server returns a public IP address. In the production setting an internal, private address is sent.

The WinSCP session config initally had the Force IP Address set to Off in the advanced settings. When we set that to On the connection to the production server worked, but the connection to the test server then failed to establish the data channel.

I would think this is a bug (though perhaps a situation not anticipated in design). If the server returns the same IP address as the initial connection for the control channel and Force IP Address is set on shouldn't that work?