There is some strange redirect at the end of the output. The truth is, that we are small ISP, so I use special tricks to be able to resolve our hosted domains even from within our network, normally by external address. But why the redirect? Is ClearOS trying to reach DNS server to resolve the name, or what is going on?

Accepted Answer

Glad it works now. There are a number of names for that process including 'NAT helper', 'FTP proxy' and others. What is basically happening is that when the FTP 'command channel' port establishes, the firewall looks at that traffic and then assumes that a random port will be chosen for the completion of the 'data channel'. The firewall looks for that packet, accepts it without prejudice and pushes it through.

I've always thought that this 'technology' of NAT helpers was a bit of a kludge because it leaves the firewall open for a spoof but without it FTP doesn't work of NAT so what can one do?

Accepted Answer

Ah, your last post reminded me I might be too much used to Mikrotik, which does plenty of stuff for you by default. It struck my mind, that there are some so called "NAT helpers". So I looked into list, and added just one additional entry for FTP, adding 2121 along to 21 port. So it was not about my SRC/DST-NAT rules, although maybe I could do it somehow manually too ...

Accepted Answer

Ok, part of the problem here will be the incoming NAT rules. I can tell from your transaction file that you have port 2121 properly forwarded to the ClearOS server. This is evident because you can authenticate ok. Where your FTP is failing is on the data channel. The proof of my claims here will be evident if you try to FTP on the local LAN segment. If you are on a machine on your 10.10.10.x network, you will see that the FTP works just fine on 2121.

Consider the following from technical information the URL listed above
"Active FTP

"In active mode FTP the client connects from a random unprivileged port (N > 1023) to the FTP server's command port, port 21. Then, the client starts listening to port N+1 and sends the FTP command PORT N+1 to the FTP server. The server will then connect back to the client's specified data port from its local data port, which is port 20.

"From the server-side firewall's standpoint, to support active mode FTP the following communication channels need to be opened:

"In order to resolve the issue of the server initiating the connection to the client a different method for FTP connections was developed. This was known as passive mode, or PASV, after the command used by the client to tell the server it is in passive mode.

"In passive mode FTP the client initiates both connections to the server, solving the problem of firewalls filtering the incoming data port connection to the client from the server. When opening an FTP connection, the client opens two random unprivileged ports locally (N > 1023 and N+1). The first port contacts the server on port 21, but instead of then issuing a PORT command and allowing the server to connect back to its data port, the client will issue the PASV command. The result of this is that the server then opens a random unprivileged port (P > 1023) and sends the PORT P command back to the client. The client then initiates the connection from port N+1 to port P on the server to transfer data.

"From the server-side firewall's standpoint, to support passive mode FTP the following communication channels need to be opened:

In short, you MUST either forward all the ports that the Passive FTP service on the ClearOS uses over your microtik firewall (Passive) or you must have the NAT devices between the client and the server aware of the fact that FTP traffic is happening on 2121 so that they can watch and allow for the data channel using their built-in ftp-proxy methods (Active). I understand that Microtik is a 'professional' firewall, so is Linksys. But they are not 'enterprise' firewalls and will NOT have the functionality to inspect Layer 4 FTP headers in order to automatically cause this to work. You are right, the problem lies with running FTP on 2121.

FTP is an awful protocol for this very reason because it is designed for networks where everything is public IP addresses and firewalls don't exist. This is why I personally DO NOT USE IT. FTP has a high learning curve, as you can see by the confusion in this thread. In addition, FTP is very inflexible. My advice to everyone is also to NOT use FTP on a ClearOS box that you have your ClearOS box behind a firewall because of the level of understanding required to make it work.

I fully agree that any FTP service on the default ports will have less problems, hence your successes in the past on other platforms that use the standard ports. The power behind ClearOS comes with the tight integration of services and user authentication. This does lead to some complexity and a learning curve to achieve optimal results.

Also, ClearOS is an open platform. Feel free to change its behavior. I'm sure the community will welcome any improvements in the design that you contribute.

Accepted Answer

How are you connecting from within the LAN, with the remote or lan ip? it's quite possible that it will work correctly for users connecting remotely, or will work if you connect via the local IP
See the following links on Proftpd behind NAT
http://www.proftpd.org/docs/directives/linked/config_ref_MasqueradeAddress.html
http://www.proftpd.org/docs/howto/NAT.html

More than likely its actually a client problem, Filezilla for example has an option for Passive data transfer where it will reconnect using the external IP if it detects that the server returned a local IP. I have no experience of the two you mentioned however...this is usually ok but only if your external IP resolves to something useful and may also cause firewall /routing issues. It appears your local DNS may be interfering? Note you can force a certain behaviour by using the 'MasqueradeAddress' directive in /etc/proftpd.conf. The above links give a bit of guidance on that

Well, I do one special trick - to allow clients on local network to connect to servers from internal address by normal resolving to public IP address, I have backward SRC NAT on central router. But even if I turned it off, it still does not work. Here are two outputs:

Local LAN (my IP - 10.10.10.20):

1) Connecting to 10.10.10.10: FTP - OK, Flexshare - OK

2) Connecting to Public IP (redirected back to server by special SRC NAT rule on central router) - FTP - OK, FlexShare - NO

Dunno what is FlexShare doing in opposite to normal FTP connection, but it tries to go via public IP. The problem is, that I need to allow my clients to upload web presentations from outside our LAN, so unless I get it working, ClearOS is no go for me ...

Also, it is easier to troubleshoot firewall issues with FTP if FTP/S is turned off.

It has been my experience that when people have problems with FTP it is almost always the firewalls fault. Most firewalls do a poor job of supporting FTP because of the data channel. Many firewalls look to the port only instead of the header of the packet to map the data channel.

Mikrotik is professional firewall. We have something like 50 MT nodes around and I have never had any problems with vsftpd and Fedora before. Also with ClearOS, normal account (not FlexShare based) works correctly (almost, connecting lasts a bit long to set-up, but works).

I'm sorry that you feel that the use of various ports is difficult but please realize that security is of great importance to us and we will always avoid situations that compromise security if we can. The use of ports allows us to separate these processes. I'm sure you'd hate to have a bad version of a web application suddenly cause your email system to also be compromised.

That being said. I agree that it needs to be more customizable so that if you are not using certain features that you can return the ports back to their native configurations. More work for us to do...thanks for your input.

I don't fully understand what you mean by compromising email system by web application, but never mind. All I wanted to say was, that if someone is not using filesharing (Flexshares), then the design is unnecessary complication and everything FTP related could work on default port 21, all you need is your GUI to address it somehow. I know it would not be so flexible, but maybe easier to set-up for end users ...

More than likely its actually a client problem, Filezilla for example has an option for Passive data transfer where it will reconnect using the external IP if it detects that the server returned a local IP. I have no experience of the two you mentioned however...this is usually ok but only if your external IP resolves to something useful and may also cause firewall /routing issues. It appears your local DNS may be interfering? Note you can force a certain behaviour by using the 'MasqueradeAddress' directive in /etc/proftpd.conf. The above links give a bit of guidance on that

Accepted Answer

ClearOS has FTP on port 21 and yes, you have to have data ports available for FTP to work even when using port 21. The port 21 ftp server is used for user ftp access which means that users can ftp to the normal port and get access to their own home directories. If we ran the flexshares on port 21 for FTP you would lose this functionality and privilege separation. You are using a flexshare and unification of privileges across multiple protocols is a requirement and therefore requires specific customizations, hence the port 2121 scenario.

To fix your problem we will need to understand your setup. Please answer the following questions:

Is the FTP server behind a separate firewall or does the FTP server have its own public address?
Is your workstation that you are trying to FTP from behind a firewall?

Also, it is easier to troubleshoot firewall issues with FTP if FTP/S is turned off.

It has been my experience that when people have problems with FTP it is almost always the firewalls fault. Most firewalls do a poor job of supporting FTP because of the data channel. Many firewalls look to the port only instead of the header of the packet to map the data channel.

I'm sorry that you feel that the use of various ports is difficult but please realize that security is of great importance to us and we will always avoid situations that compromise security if we can. The use of ports allows us to separate these processes. I'm sure you'd hate to have a bad version of a web application suddenly cause your email system to also be compromised.

That being said. I agree that it needs to be more customizable so that if you are not using certain features that you can return the ports back to their native configurations. More work for us to do...thanks for your input.

Accepted Answer

1) I really don't undestand, why is ClearOS complicating the situation. I think 90% of users would be fine with dedicated user for the web upload purposes, hence on default port 21. There could be just setting allowing to enter the chroot path, so that it could reach /var/html/virtual-domain presentation.

2) How is situation different to normal 21 passive FTP access, which works without the need to open any additional ports? And if you mean with ClearOS default FW - I have it disabled and it still does not work. Why is server doing the following?:

What does "Redirect to: my-web-public-ip" do? I have special NAT rules set, in order to allow reaching hosted domain to be reached by their public addresses, even if on local network. OK, I will check at home connecting directly to the box network, trying first with Active mode.

Generally - while I like ClearOS, I don't like using different-than-default TCP ports for various services. The same goes for webmail - why not domain.com/webmail, but using a different port? Users want to know URLs, not port numbers ...

Accepted Answer

FTP uses two separate pipes in order to work. The first is the command channel and the second is the data channel. The command channel handles authentication, directory changes, and other such things. The data channel handles the transfer of data and also the transfer of directory listings. So if you can authenticate but you cannot get a directory listing then that means that your protocol is half working. Port 2121 is the command channel in your listed scenario. I do not know what your data channel was using. This is usually a dynamic port. If you have specified a range of pasv ports (ie. 65000-65100) you will also need to open up this port range in the incoming rules of the firewall.