FTP Proxy DOesnt always let us connect to the allow list of ftps

I appreciate the shout-out. [:)]

From your description, it sounds like you are trying to use the FTP Proxy as a reverse proxy for FTP servers you have internally instead of as a proxy for internal users accessing external servers.  Is that right?

Please tell us the mode in which the HTTP/S Proxy is running, and what FTP clients your internal users have, or if they're just using the FTP capability of their web browsers.

Cheers - Bob

I appreciate the shout-out. [[:)]]

Bob, you know you really are a point of reference for our community [[:)]]

They are using Windows 7 Pro machines, they joined the domain.  There are no GPOs that affect the way they conenct to FTP.  They all use Filezilla version 3.3.5.1 in Passive mode, thats the default setting, we kept all settings default on Filezilla clients, we never changed any settings.  And finally, I am not using HTTP/S in profile mode, only HTTP/S, the first button under Web Security, and it is set in transparent mode.  Also the FTP proxy is set to transparent mode.  The ftp we connect are port 21 ftp servers, not on other ports like SFTP.  They never use ftp capability of web browsers because it is unreliable, they use ftp clients which is Filezilla.  This problem happens every day, at around midshift.

They are using Windows 7 Pro machines, they joined the domain.  There are no GPOs that affect the way they conenct to FTP.  They all use Filezilla version 3.3.5.1 in Passive mode, thats the default setting, we kept all settings default on Filezilla clients, we never changed any settings.  And finally, I am not using HTTP/S in profile mode, only HTTP/S, the first button under Web Security, and it is set in transparent mode.  Also the FTP proxy is set to transparent mode.  The ftp we connect are port 21 ftp servers, not on other ports like SFTP.  They never use ftp capability of web browsers because it is unreliable, they use ftp clients which is Filezilla.  This problem happens every day, at around midshift.

Forgive me if I'm way off on this answer as I'm trying to understand the question at hand (it seems to be all over the map)

If the users are trying to access offsite FTP servers through the local proxy and sometimes it fails, most notabily when LISTING the contents of the FTP site, then these are RULE issues, not PROXY issues. Meaning that the server is NOT likely transmitting on the same ports each and every time.

Example:
Some servers only use ports 20/21/22 for FTP style traffic. Meaning they both SEND and RECEIVE on port 21.

While others might listen for connections on port 21 but SEND from ports 4000-5000. (Or any other range of ports for that matter)

The way to check this is to watch the LIVE LOG on your ASG. 

If you are seeing blocked traffic to and from the IP addresses you're testing with, then you know you need to adjust your FTP RULE to meet you're needs. 

All server admins are different. I personally force my FTP traffic to be spread out on a range of ports, but thats just me.

In the end this is NOT a fault of the ASG or Astaro simply because it is doing what it's supposed to be doing which is blocking traffic that hasn't been Ok'd by its administrator. OK the correct ports (The ones being blocked) and the problem should be solved.

Nope!, that is not possible Jayson.  These ftp servers are hosted by our hosting provider, they are also managed boxes, meaning they manage them and we know what they manage also, so if they change ports they tell us.  These ftp sites in question are not random sites, we are not talking about ftp of for example Adobe or Microsoft which in your view I agree, we don;t know what ports they really listen to, but on our case, these are managed boxes we pay for and we use.  Thats all we have ftp to and thats the ftp allow list.  

These managed ftp servers were configured to always listen on the default ftp port which is port 21, and the IP addresses are static as well.  That's what we paid for.  To confirm this, whenever we have this block instance, I checked that right after one of these ftp sites was blocked, by disabling ftp proxy immediately, then when I try that same ftp server again, I am able to connect successfully, and watching the live log on filezilla, I see the same IP, and same port as it was a few seconds ago when I was connected via ftp proxy enabled.  

So I even disabled IPS engine completely, thinking that maybe a rule is falsely blocking this type of connection, still no luck.  So now I'm stuck on this mystery with nothing else to do but to disable fto proxy.  This problem occurred on the old astaro version 7.05 and now we upgraded to 8.003 and still it brought the problem with it!

Wait a minute!  I was looking and th technical specification of our astaro asg 120 here Astaro Security Gateway 120  and it says maximum concurrent connections 90,000  Could it be possible that we are exceeding our maximum number of conc.connecitons which is leading to this ftp blocking issue???

By the way, I was looking and the ftp logs, heres the error when the block happened, please examine it and tell me if this is a Filezilla problem so I will change the client to something else.  I searched this error online and found a few posts stating that it is a problem.  But I don;t know what that error means.

Command FEAT not implemented
connect from LAN IP e.g. 192.168.1.5

then it is repeated several times in the log and thats when my users inform me they can no longer connect to that ftp site.  Hope this helps.

Nope!, that is not possible Jayson.  These ftp servers are hosted by our hosting provider, they are also managed boxes, meaning they manage them and we know what they manage also, so if they change ports they tell us.  These ftp sites in question are not random sites, we are not talking about ftp of for example Adobe or Microsoft which in your view I agree, we don;t know what ports they really listen to, but on our case, these are managed boxes we pay for and we use.  Thats all we have ftp to and thats the ftp allow list.  

These managed ftp servers were configured to always listen on the default ftp port which is port 21, and the IP addresses are static as well.  That's what we paid for.  To confirm this, whenever we have this block instance, I checked that right after one of these ftp sites was blocked, by disabling ftp proxy immediately, then when I try that same ftp server again, I am able to connect successfully, and watching the live log on filezilla, I see the same IP, and same port as it was a few seconds ago when I was connected via ftp proxy enabled.  

So I even disabled IPS engine completely, thinking that maybe a rule is falsely blocking this type of connection, still no luck.  So now I'm stuck on this mystery with nothing else to do but to disable fto proxy.  This problem occurred on the old astaro version 7.05 and now we upgraded to 8.003 and still it brought the problem with it!

I think one of us mis-understands the other. Let me just say I'm sorry for the confusion if its me. 

With that said, let me clear up what I'm saying. 

When I say the port ranges change, that is a server side setting that allows the server to spread traffic out over a number of different ports. This is RETURN traffic, not traffic from you to them. 

Example: (assuming you're using FTPS as stated and not something like FTPES)

You call them on port 21 - This port is used for all incoming information.
You say, hello, I'm {user}, please give me file {a}
The server says, hello {user}, here is file {a} and sends it to your ftp client from and possibly to port 4000. (Port 4000 being nothing more than a made up number for this example)

Many, if not most hosting providers work in this fashion. They don't both send and receive on port 21.

The way to check this is to look in your ASG's connection log, NOT the WEB/FTP PROXY logs and not the extremely limited FTP client logs. I'm talking about the firewall.

I've had that exact same issue when I have used my own off-site servers, but we use FTPES and our servers are setup for no more than 100 users with 10 open connections each (pretty standard). If the servers you're using are setup in similar fashion then FILEZILLA client would come to a stand still often just connecting. This is because it is a very chatty client and could use up 10 connections to the server just connecting, which in turn would hang the client until those connections timed out or were forced closed. A simple test is to connect, if it hangs, force the connection closed and reconnect, if that was the problem you should NOW get right in, but you will still be waiting for other client server connections to time out.

It does help that you mentioned the connection seems to work find when the proxy is not filtering. 

What settings are you using on the proxy? Are you using anti-virus scanning? What is the file scan size on the anti-virus scanning? Are you using single or double scan? Is it possible connections are timing out while scanning is taking place? How is your proxy connection setup in your client? It should be something like ASG-URL-OR-IP:2121 (example: 192.168.2.1:2121)

yeah, i forgot to mention, and to answer your question, yes.  I disabled anti-virus scanning for ftp proxy and also for http proxy not that it has anything to do with this ftp problem.  I understand what you are telling me now.  But what I am I supposed to do now?  From what you told me, it looks like i need to go to service definitions and create a new ftp service definition with destination port to be a range of ports instead of the default service definition for ftp which is only destination port 21?  If so tell me, and if so how do I know what incoming port to open for incoming to us from the ftp server?  Do I ask the hosting company to provide the ports range.  Or do I change the ftp client to some other client.