commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Nice (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (NET-588) FTPClient.setPassiveNatWorkaround assumes host is outside site local range
Date Mon, 04 Apr 2016 16:00:26 GMT

     [ https://issues.apache.org/jira/browse/NET-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dave Nice updated NET-588:
--------------------------
    Description: 
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!

  was:
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 both remote and local networks are "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 you're connecting "site local"
-> "non-site local"... 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

I haven't yet identified a workaround within the current code!


> 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)

Mime
View raw message