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

High upload usage, cannot trace it

Sine yesterday i'm experiencing such a high upload rate that it's crippling all traffic(1s+ping to the ISP gateway).

if i click on the traffic sniffer on the dashboard, i get something that makes no sense:
Proto   Source IP   Port   Destination IP   Port   Bytes in   Pkt in   Bytes out   Pkt out
tcp [myip] 35785 67.195.168.31 25 277112 186 7020 135

WHY am i seeing "bytes IN" in the public interface when my FW is connecting to their port 25, and WHY is this traffic being counted as upload in the dashboard...

what's worse, mail manager shows nothing, realtime log shows lots of:
2010:03:09-18:09:18 astaro exim[21870]: 2010-03-09 18:09:18 128VTn-0006TK-0o Remote host g.mx.mail.yahoo.com [98.137.54.238] closed connection in response to end of data
2010:03:09-18:11:41 astaro exim[21870]: 2010-03-09 18:11:41 128VTn-0006TK-0o Remote host c.mx.mail.yahoo.com [206.190.54.127] closed connection in response to end of data
2010:03:09-18:11:41 astaro exim[21870]: 2010-03-09 18:11:41 128VTn-0006TK-0o SMTP error from remote mail server after initial connection: host e.mx.mail.yahoo.com [67.195.168.230]: 421 Message from (200.69.233.115) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
2010:03:09-18:11:43 astaro exim[21870]: 2010-03-09 18:11:43 128VTn-0006TK-0o SMTP error from remote mail server after initial connection: host f.mx.mail.yahoo.com [98.137.54.237]: 421 Message from (200.69.233.115) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html
2010:03:09-18:14:03 astaro exim[21870]: 2010-03-09 18:14:03 128VTn-0006TK-0o Remote host a.mx.mail.yahoo.com [67.195.168.31] closed connection in response to end of data 

any ideas?


This thread was automatically locked due to age.
  • What do you have in 'Local networks' in 'Intrusion Protection'?
  • if i click on the traffic sniffer on the dashboard, i get something that makes no sense:

    During the beta test for this version, I had complained about this issue but its really how you look at it. If you look at it from the Destination IPs perspective, everything makes sense otherwise its backwards. https://community.sophos.com/products/unified-threat-management/astaroorg/f/98/t/67991
    2010:03:09-18:11:41 astaro exim[21870]: 2010-03-09 18:11:41 128VTn-0006TK-0o SMTP error from remote mail server after initial connection: host e.mx.mail.yahoo.com [67.195.168.230]: 421 Message from (200.69.233.115) temporarily deferred - 4.16.50. Please refer to http://help.yahoo.com/help/us/mail/defer/defer-06.html

    Somebody sending large email attachments to yahoo that are getting deferred? I am sure the issue will fix itself once the mail is delivered or expires. You can manually delete the email in mail manager if you want some manual intervention.
  • Hi,

    I am having the same problem with high upload usage. I have traced it to mail to yahoo. Check your mail manager for outgoing messages. there will be a lot of mail to yahoo stuck in the queue. If you check your message delivery log it will have broken pipe and connection dropped messages. i am at loss as to how to fix this. If I delete the mails to yahoo the upload drop to almost zero and starts to climb again when mail is sent to yahoo. If you find a solution, please let me know how you solved it. 

    Regards

    Amal
  • balfson, local network is the internal networks in IPS

    amalsp, it's like you said, a 6MB mail to yahoo had been 23hrs in queue retrying until i deleted it.
    Weird thing is that it popped up again after being deleted but not on the mail queue.

    What i did in the meantime is activate QoS with both of the new options(fair share and optimizer upload) and also to make a traffic classifier for SMTP traffic limiting it to 50% of my practical upload(200kbps with 250kbps upper limit)

    With that, when the new mails to yahoo appeared it didn't had any effect on the quality of the connection itself(ping times to gateway dropped to 10mS) apart from a little more(acceptable) delay in small mails.

    The traffic monitor is horrible as it is, it should be showing bytes in and out in respect to ASTARO, not the destination IP.
    Right now it's centered on destination like you said in your post, so bytes IN really means "bytes coming out of ASG IN the destination".

    Addendum now:
    the high upload usage persisted ALL NIGHT but mail manager shows no spooled messages