I'm trying to send a file to a third party ftp server (hosted by Amazon it would appear) with a Camel FTP Producer, and am having an issue where I am getting Writing File failed with: File operation failed... Host attempting data connection x.x.x.x is not the same as server y.y.y.y which I've not seen before.
The producer is configured to be in passive mode, and according to the logs at TRACE level, this is enabled. (Although the error message sounds like it would relate more to an active mode issue)
The y.y.y.y IP address is one of those listed by nslookup for the target domain, so that bit makes sense. However, the x.x.x.x IP relates to a different Amazon hosting server, and so I presume some sort of hand-off or load-balancing has been performed, and the FTP client doesn't like that.
Is there some way of configuring Camel FTP to allow this (I'm presuming this is a security feature), or should passive mode allow this anyway?
I have no influence with the ftp server provider, so unfortunately I can't change anything but my client options.
Thanks for looking!
After some digging, and grepping the source code for Apache Commons FTP, the message in question is caused by a validation in the client which checks that the passive mode connection is the same as the initial server connection.
Given that this appears to be a load-balanced system, the passive mode data connection is a different IP from the target IP, and this fails the validation.
It can be fixed using Camel FTP by creating a specific instance of the FTPClient and setting remove verification off.
FTPClient ftp = new FTPClient();
ftp.setRemoteVerificationEnabled(false);
registry.put("FTPClient", ftp);
and then referencing this object in the URI for FTP
ftp://user@host:21/path?password=xxxx&passiveMode=true&tempPrefix=part.&ftpClient=#FTPClient
Clearly, by disabling this remote verification test you are making yourself more vulnerable to the FTP data being redirected or intercepted and your data being sent somewhere you didn't intend, but I guess if you're worried about that you wouldn't be using still be using unencrypted FTP in the first place.