You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-dev@incubator.apache.org by Clinton Foster <cf...@us.axway.com> on 2007/02/06 22:44:41 UTC
Allow configuring IP address for PASV response
I¹m working from a code base just before the MINA changes were checked in,
so please forgive me if this has been corrected...
As far as I can tell, there is no way to configure the IP address returned
in response to the PASV command. The config.data-connection.passive.address
configuration parameter allows configuring which local network interface the
server should accept data connections on. But if the server is behind a
firewall, the address it returns must be an external address, not a local
address like 10.10.1.2.
Given the way the code is now, it will only work with firewalls that are
smart enough to sniff the control connection and automatically rewrite the
correct external address in the PASV responses. Fortunately many firewalls
these days can do this. But obviously it won't work if the control
connection is running over SSL. So there has to be a configuration value
for specifying the external address for PASV responses.
Ideally, the server should also notice if the client's control connection
came from a local address, and if so return the local address instead of the
external address. This allows local clients to make passive data connections
to the server even if the external address is not resolvable for them.
I have added a config.data-connection.passive.external-address configuration
parameter to implement this behavior. It required updating the following
classes: DataConnectionConfig, DefaultDataConnectionConfig,
FtpDataConnection, and PASV.
Does this change make sense to everyone? If so, what would be the best way
for me to go about submitting it for review?
Clint Foster
Re: Allow configuring IP address for PASV response
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Clinton Foster wrote:
> JDK 1.4 added three new methods on InetAddress to make this
determination.
> Have a look at this code snippet:
>
> InetAddress remoteInetAddress = controlSocket.getInetAddress();
>
> if (remoteInetAddress.isLinkLocalAddress() ||
> remoteInetAddress.isSiteLocalAddress() ||
> remoteInetAddress.isLoopbackAddress()) {
> // client is local
> }
>
> The one thing I'm unsure about is whether it is correct to check both
> isLinkLocal and isSiteLocal. The Javadoc is not very helpful. If
anyone can
> provide some additional insight, that would be great.
>
> I have tested this with various different FTP clients connecting from
inside
> and outside the firewall, both SSL and non-SSL, and it works in all the
> scenarios I've tried.
After reading the JavaDocs, I'm not entirely sure this will catch the
case where the server is on a private network (192.168.*.*), e.g. behind
a NAT? Link local seems to cover only 169.254.*.* addresses.
/niklas
Re: Allow configuring IP address for PASV response
Posted by Clinton Foster <cf...@us.axway.com>.
JDK 1.4 added three new methods on InetAddress to make this determination.
Have a look at this code snippet:
InetAddress remoteInetAddress = controlSocket.getInetAddress();
if (remoteInetAddress.isLinkLocalAddress() ||
remoteInetAddress.isSiteLocalAddress() ||
remoteInetAddress.isLoopbackAddress()) {
// client is local
}
The one thing I'm unsure about is whether it is correct to check both
isLinkLocal and isSiteLocal. The Javadoc is not very helpful. If anyone can
provide some additional insight, that would be great.
I have tested this with various different FTP clients connecting from inside
and outside the firewall, both SSL and non-SSL, and it works in all the
scenarios I've tried.
Clint
On 2/6/07 3:52 PM, "Niklas Gustavsson" <ni...@protocol7.com> wrote:
> Clinton Foster wrote:
>> I¹m working from a code base just before the MINA changes were checked in,
>> so please forgive me if this has been corrected...
>>
>> As far as I can tell, there is no way to configure the IP address returned
>> in response to the PASV command. The config.data-connection.passive.address
>> configuration parameter allows configuring which local network interface the
>> server should accept data connections on. But if the server is behind a
>> firewall, the address it returns must be an external address, not a local
>> address like 10.10.1.2.
>>
>> Given the way the code is now, it will only work with firewalls that are
>> smart enough to sniff the control connection and automatically rewrite the
>> correct external address in the PASV responses. Fortunately many firewalls
>> these days can do this. But obviously it won't work if the control
>> connection is running over SSL. So there has to be a configuration value
>> for specifying the external address for PASV responses.
>>
>> Ideally, the server should also notice if the client's control connection
>> came from a local address, and if so return the local address instead of the
>> external address. This allows local clients to make passive data connections
>> to the server even if the external address is not resolvable for them.
>>
>> I have added a config.data-connection.passive.external-address configuration
>> parameter to implement this behavior. It required updating the following
>> classes: DataConnectionConfig, DefaultDataConnectionConfig,
>> FtpDataConnection, and PASV.
>>
>> Does this change make sense to everyone?
>
> Sure, I think this makes sense. There are of course FTP proxies that
> take care of this problem but as you say that would not work for SSL
> connections (unless the proxy is SSL aware, not sure if such a proxy
> exists).
>
> In your patch, how do you detect the local addresses? Would you need a
> filter saying that "if the IP match this pattern, use this PASV IP. If
> none match, use the local interface IP"?
>
>> If so, what would be the best way
>> for me to go about submitting it for review?
>
> Create a JIRA issue and attach a patch, preferably against the latest
> version of trunk. Make sure you select the radio button to allow ASF to
> use your code.
>
> /niklas
>
Re: Allow configuring IP address for PASV response
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Clinton Foster wrote:
> I¹m working from a code base just before the MINA changes were checked in,
> so please forgive me if this has been corrected...
>
> As far as I can tell, there is no way to configure the IP address returned
> in response to the PASV command. The config.data-connection.passive.address
> configuration parameter allows configuring which local network interface the
> server should accept data connections on. But if the server is behind a
> firewall, the address it returns must be an external address, not a local
> address like 10.10.1.2.
>
> Given the way the code is now, it will only work with firewalls that are
> smart enough to sniff the control connection and automatically rewrite the
> correct external address in the PASV responses. Fortunately many firewalls
> these days can do this. But obviously it won't work if the control
> connection is running over SSL. So there has to be a configuration value
> for specifying the external address for PASV responses.
>
> Ideally, the server should also notice if the client's control connection
> came from a local address, and if so return the local address instead of the
> external address. This allows local clients to make passive data connections
> to the server even if the external address is not resolvable for them.
>
> I have added a config.data-connection.passive.external-address configuration
> parameter to implement this behavior. It required updating the following
> classes: DataConnectionConfig, DefaultDataConnectionConfig,
> FtpDataConnection, and PASV.
>
> Does this change make sense to everyone?
Sure, I think this makes sense. There are of course FTP proxies that
take care of this problem but as you say that would not work for SSL
connections (unless the proxy is SSL aware, not sure if such a proxy
exists).
In your patch, how do you detect the local addresses? Would you need a
filter saying that "if the IP match this pattern, use this PASV IP. If
none match, use the local interface IP"?
> If so, what would be the best way
> for me to go about submitting it for review?
Create a JIRA issue and attach a patch, preferably against the latest
version of trunk. Make sure you select the radio button to allow ASF to
use your code.
/niklas