Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 82 replies
  • Subscribers 5 subscribers
  • Views 236023 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

Astaro eating my bandwidth

emaart
Hi

I am sitting in South Africa where bandwidth is expensive, slow and limited.
I get 5GB a month, if that is finished I'm capped and have to buy more bandwidth.

In the last 30 days, Astaro blew 7.1GB of my precious bandwidth...
5.1GB went to ec2-175-41-169-159.ap-southeast-1.compute.amazonaws.com
2GB went to several mailshell.net servers.

Note: This is not traffic from my internal network, this is my Astaro box alone, wasting my bandwidth.

How do I stop mailshell and what is being done about the amazon thing (I know some other people is also experiencing this)

Thank is advance



This thread was automatically locked due to age.
Parents
  • 0
    Amazons elastic computing cloud is something we have a long history with. We use it to distribute up2dates in record speed to all our boxes. If you remember, a large up2date used to take a long time to propagate out to all our installations and clients would have to wait for download slots and other such queuing measures. With a cloud delivery system this problem is solved. You probably dont want to take excessive measures to stop those downloads, they will likely happen anyways from a fallback up2date server. 

    We'll take a look at what could be causing excessive traffic via the up2date system, certainly 55 megs is normal, a documentation, IPS, av patterns etc...all can happen every 15 minutes and 55 megs isnt excessive. However larger amounts are. We're having a look. Thanks everyone for your feedback on this, no more forensics needed.
Reply
  • 0
    Amazons elastic computing cloud is something we have a long history with. We use it to distribute up2dates in record speed to all our boxes. If you remember, a large up2date used to take a long time to propagate out to all our installations and clients would have to wait for download slots and other such queuing measures. With a cloud delivery system this problem is solved. You probably dont want to take excessive measures to stop those downloads, they will likely happen anyways from a fallback up2date server. 

    We'll take a look at what could be causing excessive traffic via the up2date system, certainly 55 megs is normal, a documentation, IPS, av patterns etc...all can happen every 15 minutes and 55 megs isnt excessive. However larger amounts are. We're having a look. Thanks everyone for your feedback on this, no more forensics needed.
Children
  • 0 in reply to AngeloC
    Ok... I have been following this thread and it's good to see the Astaro finally interjected some comments, but it has been nearly a month and no update from Astaro on this.

    I will tell you that we have been running our AGW for over 2 years and it has steadily increased in its use of our overall bandwidth to the point where my users are affected by slow and sometimes unresponsive websurfing, etc.

    If Astaro can not get these issues worked out and explain to us what the issues are and how they will fix them, then its time to find another Security Gateway Vendor.
  • 0 in reply to ryman
    Are you still having these problems? This was fixed in the beginning of August. You are always going to have a certain amount of traffic for updates/ content filter/ rbls/ DNS. 

    Setup a netfilter firewall and you will have zero bandwidth used by the firewall, if you are going to utilize the convenience of a UTM, you will always have a certain amount of traffic used by the firewall no matter which vendor you go with. 

    By the way, this should never interfere with your web surfing, I would look for a trojan or something else in your network.
Unfiltered HTML