Jump to content

Signature Update very slow when using Squid proxy


mogobjah
 Share

Recommended Posts

Our customer is using ERA virtual appliance with Squid proxy instead of Apache HTTP proxy - because all traffic to internet has to go through an upper level proxy which requires authentication.

We are not sure why, but most of the ESET clients are not receiving update files properly from the Squid proxy. Are you able to see any issue in the attached access log? I notice that there is no ".nup" files being downloaded.

Any pointers is appreciated. 

 

access log.png

Edited by mogobjah
Link to comment
Share on other sites

  • ESET Staff

Unfortunately there is nothing suspicious visible in trace log. It shows that update.ver file was not provided from cache (TCP_MISS), but that is correct as this file is supposed to be downloaded from ESET servers even when HTTP proxy is used. Could you somehow check what is actually cached or provide more detailed log showing all requests? Depending on your endpoints version, .dat and .dll files should be cached primarily.

Link to comment
Share on other sites

  • ESET Staff
4 hours ago, mogobjah said:

Thanks Martin, i'm attaching the access.log, cache.log and squid.conf files taken from the ERA server. Please advise if you find anything amiss.

ERA Squid log.rar

Only suspicious what I can see is that there are not HIT entries for update servers, which indicates that files may not even be cached properly (but maybe they are cached on upper proxy...). This may be also caused by fact the "HIT" entries are not logged...

For example there is many entries like this:

1527809337.223    301 10.3.12.9 TCP_CLIENT_REFRESH_MISS/200 584 HEAD http://update.eset.com/ep6.6-dll-rel-sta/mod_023_pegasus_12484/em023_32_n7.dll.nup - FIRSTUP_PARENT/192.168.166.9 application/octet-stream
1527809337.568    341 10.3.12.9 TCP_MISS/200 309820 GET http://update.eset.com/ep6.6-dll-rel-sta/mod_023_pegasus_12484/em023_32_n7.dll.nup - FIRSTUP_PARENT/192.168.166.9 application/octet-stream

which means, that file was actually cached on squid, but regardless of that, HEAD request check has been sent to upper proxy and response was indicating that file has changed -> data in cache were ignored and re-download was made. It is highly improbable that file has changed so many times, so my guess is that response from upper proxy is not correct, resulting in fact that cached files in lower proxy are actually never used, as each time file is to be server to client, it is invalidated due to this HEAD checks, trigger by cache-related HTTP headers, where our servers are forcing this cache-revalidation to be sure file is current and has not changed. It would be great if you could somehow capture those HEAD requests, as it is most probable failure reason -> for example maybe upper proxy does not even support such requests? or maybe wrong headers are received ...

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...