A solution to this problem will require true MT expert status... This must be hard!

I have reviewed the many posts in the forum regarding passive FTP connections behind a MT router, and all seem to miss the fundamental challenge, which I will attempt to describe.

First, some context. The typical case we are considering is a remote FTP client attempting to connect in passive mode to an FTP server that is behind a MT router, which is connected the the Internet, and has the WAN address of this network on one of its ports. There are likely thousands of this case in current use.

As we know, all FTP connections actually use two separate port/pair connections to communicate - one port/pair for control, and a different port/pair for data transfer. And, passive FTP connections differ from active ones in one critical way - the client initiates both the Control connection and the Data connection, for helpful reasons relevant to communicating over IP, as recommended by the RFC 1579 (Firewall-Friendly FTP).

In passive FTP mode, after initial authentication is established via the control port/pair (typically port 21 on the FTP server side), the client will send the PASV command over this control connection to the FTP server, which will then initiate passive mode, and return the response that it is entering passive mode, and the IP address and Data port that it will be listening on - this looks typically like:

Entering Passive Mode (10,0,0,10,204,173)

This instructs the client to attempt to establish a Data connection to the server (remember, in passive mode, the client establishes both control and data connections) on IP address 10.0.0.10, and on port 52397.

Here's the first part of this challenge - this data connection attempt from the remote FTP client will time-out trying to connect, because the IP address 10.0.0.10 is the internal address of the FTP server - the remote client really should be trying to connect to the Data port (port 52397 in this example) on the external WAN IP address of the MT router.

The second part of this challenge is that the Data port on the FTP server for this connection (52397, is this example), which was passed to the remote FTP client on the Control channel, was generated by the FTP server for this connection uniquely, and is in all likelihood, being blocked by the firewall (back inbound) on the MT router, as well.

What we need to figure out how to accomplish is 1) how to capture the above packet being sent from the FTP server with the Data connection port in it, modify the packet data to change the IP address from the internal address (10.0.0.10 in this example) to the external WAN address, and then send it out, so that the remote client can reach the FTP router from the Internet; and 2) how to dynamically open and forward traffic destined to the Data port uniquely established by the FTP router (port 52397, in this example), to the FTP server on the internal network behind the MT router (correct internal IP address, unique data port).

First, I assume that some sort of packet inspection is required, to 'catch' this packet being sent from the FTP server with the IP address and port number in it, and second, some sort of packet editing, to change the IP address to the WAN address, and third, some sort of dynamic opening and forwarding of packets with the data port destination to the FTP server.


If anyone has figured this out (and, I assume someone must have figured this out, as this is such a common case), or there is a clear explanation posted somewhere in the wiki or on the forum, I'd really appreciate hearing about it.

I will nominate them for MikroTIk Superhero status.......

Problem #1:
If the ftp server is sending the private address to the clients, this is a problem with your ftp server. Look in your ftp server settings to fix this.


Problem #2:
In your FTP server, designate a passive port range (like 50000 - 51000).

Then, forward those ports in mikrotik to the ftp server.

So, when a user connects, the pasv ftp server will tell the client to connect to some port within that range... and that range is already forwarded to your ftp server.

Thanks for the response, jandafields.

Yes, you're right, the FTP sever I'm using is capable of 'knowing' it's WAN address. It's a IIS 7.5 Microsoft server. It's been a long time since I've set up an FTP server, and way back then, the only way to do what this does was to use a stateful router capable of deep packet inspection and modification (to modify the outgoing FTP server response to PASV) - a pretty complex feature on a historically pretty expensive router box, and I did not know if anyone had accomplished this on a MikroTik.

And yes, on your second suggestion, I've forwarded a range of ports to the FTP server, which is capable of dynamically opening the firewall for the specifc inbound port sent out in response to the PASV. Here again, a stateful assessment of inbound traffic could/would enable the router itself to dynamically open/forward ports as well, but opening and forwarding a handful of ports for inbound data connections to the FTP server - IF it's equipped with a dynamic firewall - is pretty good security, although not ironclad.

These MikroTik routers are quite impressive for the size and cost. I do imagine that someone has written a packet inspection/editing script for it, but I haven't found it yet - and I am too far removed from proficient programming skills to attempt without some 'examples' to guide me.

Thanks again for responding - it forced me to 'read the manual' on this FTP server's capability, to discover it's full -and I assume contemporary - potential.

Here's some karma...