mina-ftpserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Latorre <dvl...@gmail.com>
Subject Re: FTP Data Channels Through Reverse Proxy
Date Wed, 21 Aug 2019 23:03:59 GMT
Hi Kenneth,

Shouldn't you receive the proxy address as a response to PASV when going
through the proxy? Otherwise it would bypass the proxy, but I'm assuming
you should not  connect directly from the client to the server and that's
why you need a proxy. I'm a bit puzzled since you state that the proxy
receives the response to MLSD but the IP that the client sees for PASV is
the same in both cases.

Your client log for the proxy case does not show any listing as a response
for MLSD, so it's difficult to know what's going on. If you cannot get any
logs for that, get some network traces with tcpdump and check what's going
on. Enabling more detailed logging in the client might also help (you can
configure that in the Filezilla settings).  Server logs might also prove
useful.

In any case  I don't see how this would be caused by Ftpserver with the
information you've given.



On Wed, 21 Aug 2019, 21:56 Kenneth Taylor, <kenneth.taylor@dataexpress.com>
wrote:

> We are trying to get Apache FTP Server to work behind a reverse proxy. The
> only thing not working is the data channels. We use an Ftplet to intercept
> and handle the PASV command and substitute our proxy’s IP and port in the
> PASV response. That all seems to work fine.  We are testing it with
> FileZilla client and our server works perfectly when connecting directly to
> the server but fails when going through the proxy.
>
>
>
> We can see the data connections being established on both the server and
> the proxy. Our proxy logs every forwarded message and we can see that all
> client and server messages are being forwarded both ways.
>
>
>
> The problem is that after the PASV command happens the next comand is MLSD
> and we can see the server sending the correct response and the proxy is
> forwarding the listing. But the client interprets the response incorrectly
> and closes the session.  After looking at this for many many hours we’re
> stumped.
>
>
>
> Our Proxy is a very simple IO streams forwarder, with a control connection
> to tell the Proxy when to open data channels that forward back to the data
> channel opened by Apache on the Server.
>
>
>
> This is the client log when connecting direct:
>
>
>
> 14:10:44 Command: PASV
>
> 14:10:44 Response: 227 Entering Passive Mode (192,168,0,173,40,122)
>
> 14:10:44 Trace:       Binding data connection source IP to control
> connection source IP 192.168.0.92
>
> 14:10:44 Command: MLSD
>
> 14:10:44 Response: 150 File status okay; about to open data connection.
>
> 14:10:44 Response: 226 Closing data connection.
>
> 14:10:44 Listing:      Size=0;Modify=20190814174646.670;Type=dir; Monthly
>
> 14:10:44 Listing:      Size=0;Modify=20190814180307.721;Type=dir; Weekly
>
> 14:10:44 Listing:      Size=0;Modify=20190814174833.915;Type=dir; Daily
>
> 14:10:44 Listing:      Size=0;Modify=20190814175140.777;Type=dir; Archive
>
> 14:10:44 Status:      Directory listing of "/" successful
>
>
>
> This is the client log when connecting through the proxy:
>
>
>
> 14:37:16 Command: PASV
>
> 14:37:16 Response: 227 Entering Passive Mode (192,168,0,91,202,228)
>
> 14:37:16 Trace:       Binding data connection source IP to control
> connection source IP 192.168.0.173
>
> 14:37:16 Command: MLSD
>
> 14:37:16 Response: 150 File status okay; about to open data connection.
>
> 14:37:16 Response: 226 Closing data connection.
>
> 14:37:16 Error:       Disconnected from server: ECONNABORTED - Connection
> aborted
>
> 14:37:16 Error:       Failed to retrieve directory listing
>
>
>
> One weird thing we see is that the “226 Closing data connection” shows up
> on the proxy after the MLSD listing is returned. When connecting direct it
> is before the listing in the client log, but in all cases these messages
> are coming from the same server so that may be a logging anomaly.
>
>
>
> Thanks for any help.
>
> Ken
>
>
>
> Disclaimer: This email from DMBGroup LLC, DMB Consulting Services LLC, or
> the personnel associated with either entity (collectively "*DMB*") and
> attachments, contain *CONFIDENTIAL, PRIVILEGED AND PROPRIETARY *information
> for exclusive use of the addressee individual(s) or entity. Unauthorized
> viewing, copying, disclosure, distribution or use of this e-mail or
> attachments may be subject to legal restriction or sanction. If received in
> error, notify sender immediately by return e-mail and delete original
> message and attachments. Nothing contained in this e-mail or attachments
> shall satisfy the requirements for a writing unless specifically stated.
> Nothing contained herein shall constitute a contract or electronic
> signature under the Electronic Signatures in Global and National Commerce
> Act, any version of the Uniform Electronic Transactions Act or any other
> statute governing electronic transactions. Opinions and statements
> expressed in this e-mail and any attachments are those of the individual
> sender and not necessarily of DMB. DMB does not guarantee this e-mail
> transmission is secured, error or virus-free. Neither DMB nor the sender of
> this e-mail accepts liability for errors or omissions in the contents of
> this e-mail, which arise as a result of e-mail transmission. .
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message