[
https://issues.apache.org/jira/browse/NET-588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15721254#comment-15721254
]
Thai H commented on NET-588:
----------------------------
I've just created a pull request at https://github.com/apache/commons-net/pull/5
The change will allow overwriting PASV reply address by implementing method
"String resolve(String hostname) "
> FTPClient.setPassiveNatWorkaround assumes host is outside site local range
> --------------------------------------------------------------------------
>
> Key: NET-588
> URL: https://issues.apache.org/jira/browse/NET-588
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 3.1, 3.3, 3.4
> Reporter: Dave Nice
>
> We have a NAT firewall between two "site local" 10.x networks. The effect is
> that the FTP library tries to make data connections to the wrong host because
> the passive NAT workaround doesn't operate if the FTP connection is made to a
> "site local" private address and the host returned in the PASV reply is also
> "site local".
> I see that Damon Dan references pretty much the exact issue within bug
> NET-363 when the workaround was originally introduced.
> Users with "site local" networks would be quite at liberty to subnet within
> the network, I guess, to suit their administrative needs, so this seems like
> a valid issue.
> Options I can see:
> 1) Include a way of forcing the workaround in place
> 2) Remove the selectivity around rewriting the host only if the PASV reply is
> "site local" and original host isn't... Issue here is around a server that
> has multiple endpoints for data connections?
> 3) Allow the user to specify their own data host via API
> 4) Check for whether the PASV reply address is in a different subnet to the
> original host we connected to and apply the workaround if so
> I haven't yet identified a workaround within the current code!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
