Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 2 subscribers
  • Views 951 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

WAN link maxed (to 216.168.105.89 via TCP 80?)

atarso
I had this happen a while back and couldn't identify the cause, and it just happened again this morning.  I notice things are brutally slow across network (surfing, VPN to work, etc.) so I check the interfaces and I see them maxed out doing outbound TCP/80 to two addresses, 216.168.105.89, and 216.168.105.87 from my WAN link.  My internal network link and DMZ link are essentially unused at these times but I sniffed them just to be sure - yep, nothing going on.  So it looks like it's originating from my ASG...?  Next time it happens I'll try to do a trace from the console of the ASG to try and see what it is...

The first time I turned off every device on my network one by one and it didn't stop until I turned off the interface for the WAN link so it has to be from ASG outbound but what on earth is it?  It ran for 14 hours using up 27GB of data (cool!  But not really...LOL).

Just posting so I can track the progress and let you know what happens (and if maybe anyone else has ideas and if someone else is experiencing this).  Last time it happened was about 27 days ago (I ended up rebooting the ASG to make sure it wasn't anything wonky in the config or whatever).

When I looked up the IP I think it told me it was akamai so I thought of windows updates right away, wonder if it hung on to connection from my windows machine doing updates and kept chatting or something?


This thread was automatically locked due to age.
Parents
  • 0
    Yep, it's definitely Akamai.  I see those same IPs being hit as well, but the source of the traffic is definitely an internal Win PC.  Do a search in the Web Filtering/Content Filter (depending on version of Astaro) log.
  • 0 in reply to Scott_Klassen
    Ya, that's the thing, I checked my packet filter logs while this was happening but I didn't see anything there (plus I had turned all my devices off one by one and it was still going strong after everything but ASG box was off).  Time will tell [:)]
  • 0 in reply to atarso
    atarso, if you have HTTP Proxy enabled, that is why the updates continue to download from akamai even after you shut the clients down; unless you have proper exceptions in place, you can have a single update for a client PC fail repeatedly (due to timeouts waiting for a response from the proxy), and then it will request the update again... and the proxy known no better, so it starts downloading again, thus "stacking" the downloads, and wiping out all available bandwidth on your ISP link.

    I've seen this happen time and time again, especially with update programs that are not proxy-aware or "tolerant." ... case in point, AOL updates (ugh I hate AOL, but have at least one customer that insists on at least using them) can do this quite easily, especially if the ISP (cable in this case) has local caching servers (akamai) in a datacenter with a straight shot to the client -- this swamps the connection in no time.  The answer in that case was for us to block the URL that the updates were coming from manually in the proxy settings.
Reply
  • 0 in reply to atarso
    atarso, if you have HTTP Proxy enabled, that is why the updates continue to download from akamai even after you shut the clients down; unless you have proper exceptions in place, you can have a single update for a client PC fail repeatedly (due to timeouts waiting for a response from the proxy), and then it will request the update again... and the proxy known no better, so it starts downloading again, thus "stacking" the downloads, and wiping out all available bandwidth on your ISP link.

    I've seen this happen time and time again, especially with update programs that are not proxy-aware or "tolerant." ... case in point, AOL updates (ugh I hate AOL, but have at least one customer that insists on at least using them) can do this quite easily, especially if the ISP (cable in this case) has local caching servers (akamai) in a datacenter with a straight shot to the client -- this swamps the connection in no time.  The answer in that case was for us to block the URL that the updates were coming from manually in the proxy settings.
Children
No Data