Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 1 subscriber
  • Views 5490 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

gnsec
I have created network definitions for ftp hosts and added them to a group.  I assigned this group as the ftp allowed list in the ftp proxy.  I cannot understand why does astaro sometimes block access to these sites and in that instance i have to disable ftp proxy to be able to connect???  Something is definately wrong with Astaro, someone must have a solution as this is totally stupid!  Also this is happening everyday so sometimes it allows us to connect and sometimes it doesn't.  Is it the Intrusion Prevension rules that are triggered for this false alarm?  If so which rule is it so I can disable it, this is rediculous, so many issued with Astaro on the forum and we had so many issues since we bought it.  Fortinet doesnt have these issues.  Can Balfson solve this mystery for me please.


This thread was automatically locked due to age.
Parents
  • 0
    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!
Reply
  • 0
    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!
Children
  • 0 in reply to gnsec
    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)