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

Uugh

Astaro and Community:

I saw the announcement on distrowatch that Astaro had released 7.1 and grew excited.  I've been anticipating this day for quite a while after struggling with v6.3-v7.0.

Boy was I disappointed.

Once again, Astaro's performance continues to suck.  The HTTP proxy is virtually useless, OSPF routing is buggy at best (specifically digest issues), and the content filter continues to be a pain in the a$$. [:@]

I had high hopes.  I just got into a position with my company that I thought about contacting Astaro about a possible resell opportunity since my clients are always asking me about security solutions and my opinion.  My answer has always been, "Take a look at Astaro but check other vendors."  That has now changed -- it's now, ".. check other vendors and forget about Astaro." [H]

I'm sorry.. but my trust has been violated too many times.  There are other fish in the sea that provide better service, better performance, and better relationships with the open source community that Astaro derives the bulk of their functionality from.

Guys; you have the opportunity to change this -- HTTP is the bulk of what your customers are focused on.  If your client's can't have their workers access websites at a decent clip and have content filtering (forget virus protection!! It belongs on the damn workstation ANYHOW) you're product is virtually worthless.  It's the largest damn protocol used on the Internet besides FTP.  Focus on it for a while.. [:(]

This is a sad day that I have to recommend MS ISA 2006 and MS Forefront over Astaro (although not my first choice by any means of the stretch).  It's been a fun ride.. good luck! [H]


This thread was automatically locked due to age.
Parents
  • Hi jwwstpete,

    as mentioned in other postings, as a workaround for bad performance caused by dropped HTTP proxy packets (have a look in your packetfilter log) you can create the following packetfilter rule:
    External Address, Any, Any, Allow

    If you have multiple external address, look at the source ip in the packetfilter log.

    We found the cause and will release an official fix in the next update.

    Thank you for the report.

    Regarding your problems with OSPF: you are actually the first customer reporting an OSPF related issue ever. Please contact me via email (dstutz(at)astaro.com). 

    Kind Regards,
    Daniel
  • Hi jwwstpete,

    as mentioned in other postings, as a workaround for bad performance caused by dropped HTTP proxy packets (have a look in your packetfilter log) you can create the following packetfilter rule:
    External Address, Any, Any, Allow

    If you have multiple external address, look at the source ip in the packetfilter log.

    We found the cause and will release an official fix in the next update.

    Thank you for the report.

    Regarding your problems with OSPF: you are actually the first customer reporting an OSPF related issue ever. Please contact me via email (dstutz(at)astaro.com). 

    Kind Regards,
    Daniel



    OK, this seems to improve the http proxy performance.

    But the firewall is also dropping some of the packets that the proxy is returning to the user.
    Internal Address:8080 -> User IP:****
    an example would be 192.168.1.1:8080->192.168.1.2:1234.
    This also shoudn't be dropped...
    I could also make rules Internal Address:8080 -> Internal Network(s):any
    but this should be default behavior...
  • I've seen this a bit... I've also had this happen on Version 6 before, and had to create manual rules to correct it (as I have on V7 systems)... it appears that the IPTABLES gets out of order...
  • Thank you for the posts.  I thought it was my just the users usual statements.  This also fixes an issue we were having with the SSL client.  Remote users were complaining of it being slow and 'stuttering'.  Sometimes the mouse click would work and sometimes it took several clicks to work.  Upon looking through the logs I saw were port 443 packets were also being dropped back to the SSL clients.  Feedback I've had since adding the packet filter rule has been postive.  Again thanks.
Reply
  • Thank you for the posts.  I thought it was my just the users usual statements.  This also fixes an issue we were having with the SSL client.  Remote users were complaining of it being slow and 'stuttering'.  Sometimes the mouse click would work and sometimes it took several clicks to work.  Upon looking through the logs I saw were port 443 packets were also being dropped back to the SSL clients.  Feedback I've had since adding the packet filter rule has been postive.  Again thanks.
Children
No Data