FTP: PRET support / use WAN ip for PORT

[za222]

Hi,

i just noticed TC is unable to connect to FTPs running some versions of DRFTPD when behind a router:

Code: Select all

PASV
500 You need to use a client supporting PRET (PRE Transfer) to use PASV
PORT 192,168,0,1,11,136
501- ==YOU'RE BEHIND A NAT ROUTER==
501- Configure the firewall settings of your FTP client
501-   to use your real IP: xxx.xxx.xxx.xxx
501- And set up port forwarding in your router.
501- Or you can just use a PRET capable client, see
501    http://drftpd.org/ for PRET capable clients

PASV mode wont work as TC doesnt support PRET.
And active mode wont work as TC always sends LAN ip but drftpd requires the external WAN ip.

Other FTP clients are able to set something like:

Code: Select all

force active mode to use this ip: <WAN ip> | <dyndns alias>

where you can put either your static WAN ip or - if you have a dynamic ip - some DynDNS alias.

This way the problems are solved.

Is it possible to do that somehow in TC?

[ghisler(Author)]

PASV mode wont work as TC doesnt support PRET.

See the thread in the English forum above about PRET.

And active mode wont work as TC always sends LAN ip but drftpd requires the external WAN ip.

My hardware firewall appliance automatically converts the LAN IP to the WAN IP. This is so-called statful packet inspection. Of course only good firewalls support it (I'm using a Zyxel Zywall).

Ho should TC know the WAN IP address? And how should the NAT router know that it has to forward the port to your client if it doesn't support stateful packet inspection?

[za222]

Ho should TC know the WAN IP address? And how should the NAT router know that it has to forward the port to your client if it doesn't support stateful packet inspection?

Not directly.
For example in FlashFXP there is an option called:

Code: Select all

force active mode to use this ip: 

where you else can set a static ip manually.
in case of a dynamic ip you also can set a dyndns host here.

Any time TC needs to send a PORT xxx,xxx,xxx,xxx,xx,xx command
It either uses the static ip entered there or it resolves the dyndsn alias to an ip.

There is also an option called:

Code: Select all

only use the following ports for active mode connections

where you can set a port range.
If you forward this port range in the router to your PC active mode works perfectly.

[riptide]

This is exactly what I'm looking for.
Since not all firewalls support stateful packet inspection or whatever it's called an option to specify your external IP to send in the PORT command is absolutly needed.
The option to specify port range to be used in active mode is already in place so why not the option to specify the external IP to be used in active mode?

I first looked in the support forum to see if I found a workaround for this but all solutions end in "use PASV mode". But since not all FTP servers support this and not all firewalls support stateful packet inspection the only thing needed is a field to specify your external IP which is then sent instead of the internal ip in the PORT command. And they all lived happily ever after

[Modem-Man]

Hi,

i just noticed TC is unable to connect to FTPs running some versions of DRFTPD when behind a router:

PASV mode wont work as TC doesnt support PRET.
And active mode wont work as TC always sends LAN ip but drftpd requires the external WAN ip.

[...]

Is it possible to do that somehow in TC?

"PRET" is not even an ietf-draft
I would suggest to implement anything useful command - but not such bad documented, unnessesary and proprietary scrap

It is still a risk to implement ietf-draft commands, because any draft can change before getting a final "RFC" state. In such a case you'll have a program with incompatible behaviour, once your draft got RFC inbetween
But, as stated above, "PRET" is less than an ietf draft ...

The way, software engineers doing, is:
0 - seeing a problem
1 - having an idea
2 - playing around with it
3 - writing a first ietf-draft-proposal
4 - revide this proposal with other peoples minds, multiple times
5 - releasing it as so called "RFC"
6 - waiting for the IETF guys to mark this RFC as "STD" or "BCP"

STD is "Internet Standard", BCP is "Best Current Practice" (somewhat less than a standard)

"PRET" is in stage 2.

Most FTP-Commands (from RFC959) are in stage 6.
Some FTP-Commands (Directory Access) are in Stage 5. AFAIK, TotalCommander have not implemented yet any stage 4 stuff. And this is damn right this way!

The second way you asked for, an optional configuration field for an 'dyndns'-name is much better here. TC can do this very simple way. Just resolving the dyndns Internet-IP before sending "PORT" command, then faking the PORT args with the new IP.
This can be done without raping the standard and - by the way - it fixes an RFC 2577 issue. RFC 2577 aware servers don't send data to IP other than the IP the control connection comes from. And with clients behind NAT, the Control-IP is the same Internet-IP, the faked PORT command would send.


There is still ONE problem that the user must be aware of: if we fake the PORT's IP, we have still our local TCP port number. So this will only work, if the Port-Window from Internet is mapped 1:1 to the Port-Window of TC.
(At Fritz!Box DSL Modem you can do 1:1 mapping as well as any offset).

Of course, TC can also ask this mapping at configuration time. But there is NO way to automate this...

with best regards,
Modem Man

[singeroi]

use an alternative ftp client instead..

[Modem-Man]

Update:

"PRET" is not even an ietf-draft
I would suggest to implement anything useful command - but not such bad documented, unnessesary and proprietary scrap

...

AFAIK, TotalCommander have not implemented yet any stage 4 stuff. And this is damn right this way!

I am working on extension of an ietf draft for the command "HOST". This could resolve such problems just if:

a) the ftp client simply sends "HOST ftp.whatever-i-opened-yet.home" or "HOST 123.456.789.123". At last he does so, after he noticed FEAT response with HOST. Maybe earlier, just in front of USER or so.

b) the ftp server checks, if his own NIC owns same address that "HOST" told - then ignore this command. Then the server looks if he is in a local private network (192.168, 10.,172.2x) and configured to be the same host that was told to him. If so, he responds with "host-faked" adresses in his PASV response.

Benefit:
1) Both FTP Server and FTP Client can reside in private local networks with NAT and/or behind a firewall. SOCKS4/5 is an optional adition, if the Firewall can not map a port windows by configuration.
2) Command "HOST" already exists for multi-hosted virtual servers as an ietf draft. The new meaning does not collide with the current draft. It just extends its possibilities.

this are my 5 cents...

[mrchet123]

Thanks to that information. before I hadn't discover the TC. should think it is simple.