From ftpserver-dev-return-478-apmail-incubator-ftpserver-dev-archive=incubator.apache.org@incubator.apache.org Tue Feb 06 23:07:21 2007 Return-Path: Delivered-To: apmail-incubator-ftpserver-dev-archive@www.apache.org Received: (qmail 99939 invoked from network); 6 Feb 2007 23:07:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 6 Feb 2007 23:07:21 -0000 Received: (qmail 74109 invoked by uid 500); 6 Feb 2007 23:07:28 -0000 Delivered-To: apmail-incubator-ftpserver-dev-archive@incubator.apache.org Received: (qmail 74032 invoked by uid 500); 6 Feb 2007 23:07:28 -0000 Mailing-List: contact ftpserver-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ftpserver-dev@incubator.apache.org Delivered-To: mailing list ftpserver-dev@incubator.apache.org Received: (qmail 74019 invoked by uid 99); 6 Feb 2007 23:07:28 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2007 15:07:28 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (herse.apache.org: local policy) Received: from [208.67.129.15] (HELO mail1.cyclonecommerce.com) (208.67.129.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 06 Feb 2007 15:07:19 -0800 Received: from 10.10.12.44 ([10.10.12.44]) by mail1.cyclonecommerce.com ([10.1.0.56]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Feb 2007 23:06:58 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Tue, 06 Feb 2007 16:06:57 -0700 Subject: Re: Allow configuring IP address for PASV response From: Clinton Foster To: Message-ID: Thread-Topic: Allow configuring IP address for PASV response Thread-Index: AcdKQ3/BvkIfKrY2EduZJQARJDopLA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org JDK 1.4 added three new methods on InetAddress to make this determination. Have a look at this code snippet: InetAddress remoteInetAddress =3D 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 insid= e 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" wrote: > Clinton Foster wrote: >> I=B9m working from a code base just before the MINA changes were checked i= n, >> so please forgive me if this has been corrected... >>=20 >> As far as I can tell, there is no way to configure the IP address return= ed >> in response to the PASV command. The config.data-connection.passive.addr= ess >> 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 loca= l >> address like 10.10.1.2. >>=20 >> 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 t= he >> correct external address in the PASV responses. Fortunately many firewal= ls >> 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 valu= e >> for specifying the external address for PASV responses. >>=20 >> Ideally, the server should also notice if the client's control connectio= n >> 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 connect= ions >> to the server even if the external address is not resolvable for them. >>=20 >> I have added a config.data-connection.passive.external-address configura= tion >> parameter to implement this behavior. It required updating the following >> classes: DataConnectionConfig, DefaultDataConnectionConfig, >> FtpDataConnection, and PASV. >>=20 >> Does this change make sense to everyone? >=20 > 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). >=20 > 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"? >=20 >> If so, what would be the best way >> for me to go about submitting it for review? >=20 > 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. >=20 > /niklas >=20