mogobjah 0 Posted May 28, 2018 Share Posted May 28, 2018 (edited) 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. Edited May 28, 2018 by mogobjah Link to comment Share on other sites More sharing options...
ESET Staff MartinK 384 Posted May 28, 2018 ESET Staff Share Posted May 28, 2018 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 More sharing options...
mogobjah 0 Posted June 1, 2018 Author Share Posted June 1, 2018 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 Link to comment Share on other sites More sharing options...
ESET Staff MartinK 384 Posted June 1, 2018 ESET Staff Share Posted June 1, 2018 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 More sharing options...
Recommended Posts