SOCKS in WG 6 different from WG 5.2.3 - ftp problems

[Jens]

Encrypted FTP (EFTP3) stopped working after upgrading to WG 6.0. It worked fine in encrypted mode using SOCKS 5 connection to the server with WG 5.2.3. After upgrade to WG 6.0 release version, it stopped working in encrypted mode. It works in clear mode but not encrypted. Is this a bug in 6.0 or is the change in behaviour intended? Using SOCKS was the only way we could get encrypted ftp to work so it is very unfortunate if this possibility is no longer there.
Please advise if this is a bug or intended change.

[adrien]

Hi Jens

The main change we made in SOCKS was to bring it up to date a bit with transparent proxy operation.

So now, if you have a WWW proxy on port 80, which is set to intercept connections on port 80, then if a client machine uses the SOCKS server to connect to a site on port 80, this will be intercepted.

What this means, is that for your encrypted FTP application, if your encrypted FTP client is connecting out to a server on a port that you have a WinGate service also listening on (and intercepting connections on), then this connection could be intercepted.

Does the client connect on port 21 still? If so, disable transparent proxy in the FTP proxy and see if that helps.

Adrien

[Jens]

Well, it seems that the changes has had a disastrous effect on my applications that tested out fine with 5.2.3.
I use port 21 for ftp and the system must support both encrypted and unencrypted ftp. If I turn transparent redirection off, encrypted ftp works as such but traffic accounting goes haywire, it seems to give random results, downloading a 150 kB file which took a couple of minutes max gave in one test a traffic indication of 1.5 MB and 3500s online. A second identical test gave an measured 6.2 kB traffic volume and 199s online.
Another issue is that to get Kaspersky antivirys to work for clear ftp downloads, it is necessary to have transparent redirection on.
With transparent redirection on, it seems that the ftp client tries to exchange public keys with the proxy server instead of the ftp server at the other end.
All this worked as desired with 5.2.3 so, so far version 6 has only given me weeks of confusion and grief.
However, I am very grateful for the quick and good responses to my questions.

[adrien]

You aren't using SSL on the FTP proxy are you?

Looks like you need to be able to use TR and not at the same time. We can put a switch into the SOCKS server to allow it to be intercepted or not, rather than have it controlled by the other servers.

Adrien

[Jens]

The following is an extract from the documentation of EFTP3.
+++++++++++++++++
EFTP functions exactly the same as any other FTP Client and Server. The only difference is that before the standard USER and PASS authentication handshake, the client sends to the server its public key, and the server answers it with its own public key, after encrypting it with the client’s public key. Another difference is that the client and server set up another Key to use for file transfers.
+++++++++++++++
The developer of EFTP stated in a post some time ago that EFTP client would have problems traversing through a proxy server but that SOCKS should work fine. Testing with WG 5.2.3 supported that statement but it seems that the changes made in 6.0 has caused problems with this application.

I have however tested tested with Globalscape Secure Ftp server and CuteFtp client today and that seems to work ok in secure mode through WinGate with TR active so we may go for that instead if it checks out well.