FTP Transparent Proxy

Use this forum to post questions relating to WinGate, feature requests, technical or configuration problems

Moderator: Qbik Staff

FTP Transparent Proxy

Postby davidting » Mar 25 09 6:05 pm

Hi,

When I turned on the transparent proxy, the FileZilla give the following error:

Response: PBSZ
Response: PROT
Response: 211 End.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: TYPE I
Response: 200 TYPE is now 8-bit binary
Command: PASV
Response: 227 Entering passive mode (192,168,16,200,5,148)
Status: Server sent passive reply with unroutable address. Using server address instead.
Command: LIST
Error: Connection timed out
Error: Failed to retrieve directory listing

How to get this FTP connection to work through the transparent proxy?

Thanks.

David
davidting
 
Posts: 13
Joined: Mar 24 09 9:05 pm

Re: FTP Transparent Proxy

Postby logan » Mar 25 09 6:42 pm

Hi David,

I have received a few reports of this same bug in 6.5.2. The FTP download is timing out around 30 seconds after the LIST command is issued in either Passive or Active mode. As of yet, I do not have any information that I can share on the issue, but will let you know once we have a solution.
logan
Qbik Staff
 
Posts: 671
Joined: Oct 19 06 2:49 pm
Location: Auckland, New Zealand

Re: FTP Transparent Proxy

Postby davidting » Mar 26 09 2:37 pm

Hi logan,

I have no choice but to turn off the FTP Transparent Proxy for now. Please let me know when this is fixed.

David
davidting
 
Posts: 13
Joined: Mar 24 09 9:05 pm

Re: FTP Transparent Proxy

Postby logan » Mar 26 09 8:14 pm

We have successfully reproduced this problem and have tracked it down to a bug in the FTP software on the client computer. Here are the details.

When WinGate Intercepts an FTP connection, the client is blissfully unaware that it's actually talking through a proxy, and instead thinks that it is talking directly to the FTP server that it connected to. This is why the intercept is called "transparent", since the client has no idea that it's there.

When the client issues the PASV command in order to obtain an IP and port from the FTP server which it can make a data connection to, WinGate intercepts the PASV response from the FTP server and replaces the IP and port in that response with it's own IP and port so that the client will make it's data connection to the WinGate server where WinGate is waiting to handle the connection on behalf of the client.

The problem is that the client software is getting too smart for it's own good. Because the client thinks it's talking to an IP address on the Internet, when it see's a private IP address in the PASV response, it instantly assumes that the FTP server that it's talking to made a mistake and sent it's private IP address instead of it's public IP. In order to be the hero that saves the day, the client doesn't bother attempting to use the private IP that was issued in the PASV response. It simply attempts to make the connection directly to the public IP of the FTP server, but it uses the passive port that WinGate issued the client which is different from the passive port that the FTP server issued WinGate. The FTP server will not expecting the connection on the passive port that the client is trying to use, so any command that the client sends will fall on deaf ears.

This behaviour breaks FTP spec, so we have deemed it as a bug in the FTP client software. The client should at least try the private IP that WinGate issued before assuming that it was a mistake by the FTP server, and only if that attempt fails would it become logical for the client to try the FTP servers public IP instead.

If you set the FTP Proxy manually in the FTP clients, then client is made fully aware that it's talking to a proxy and not the actual FTP server, so the FTP connection will work fine without this problem.

Also, this problem should not effect Active FTP connections made through the FTP Proxy since Active FTP relies on the client telling the server which port it wants to receive the data connection on. In this case, the FTP Proxy and the client both share the same public IP, so there is no confusion. Using Active FTP through the proxy requires opening up the ephemeral port range from the Internet to the WinGate server which could be risky if your server is not well secured.

Although this problem is not being caused by WinGate, we are looking at ways WinGate can be changed to accomodate for this behaviour of the clients, but any change in WinGate will likely be a while off since this will require synchronous modifications to multiple components of WinGate.
logan
Qbik Staff
 
Posts: 671
Joined: Oct 19 06 2:49 pm
Location: Auckland, New Zealand

Re: FTP Transparent Proxy

Postby davidting » Mar 26 09 10:49 pm

Thanks for the explanation. It is fine for us to set the proxy manually as it doesn't involve too many computers.

David
davidting
 
Posts: 13
Joined: Mar 24 09 9:05 pm


Return to WinGate

Who is online

Users browsing this forum: Bing [Bot] and 2 guests

cron